Re: [XaraXtreme-dev] Re: configure.in:305: error: possibly undefined macro: AM_GNU_GETTEXT

[Vasil Dimov <vd@xxxxxxxxxxx>]

On Tue, Jun 06, 2006 at 10:52:11AM +0100, Alex Bligh wrote:
> Vasil,
> 
> Vasil Dimov wrote:
> >Hola! After passing some final tests I upgraded the FreeBSD port
> >graphics/xaralx-devel from 0.5r1184 to 0.5r1250 removing almost all
> >customizations and hacks which were necessary for early releases to be
> >build under FreeBSD.
> 
> Great. Are you doing anything more peculiar than passing environment
> variables now? IE are you still applying any patches (and if so,
> which)?
> 

I think this can be easily fixed in the svn:
--- patch-PreComp_Makefile.am begins here ---
--- PreComp/Makefile.am.orig	Mon Mar 27 09:58:41 2006
+++ PreComp/Makefile.am	Mon Mar 27 09:58:52 2006
@@ -13,10 +13,10 @@
 camtypes.h.gch: camtypes.h
 	if $(CXXCOMPILE) -x c++-header -MT $@ -MD -MP -MF "$(DEPDIR)/camtypes.h.Tpo" -c -o $@ $<; \
 	then mv -f "$(DEPDIR)/camtypes.h.Tpo" "$(DEPDIR)/camtypes.h.Po"; else rm -f "$(DEPDIR)/camtypes.h.Tpo"; exit 1; fi
-	make -C ../Kernel clean
-	make -C ../wxXtra clean
-	make -C ../tools clean
-	make -C ../wxOil clean
+	$(MAKE) -C ../Kernel clean
+	$(MAKE) -C ../wxXtra clean
+	$(MAKE) -C ../tools clean
+	$(MAKE) -C ../wxOil clean
 	
 
 
--- patch-PreComp_Makefile.am ends here ---

This is necessary because GNU make in installed as gmake under FreeBSD.
If MAKE is not initialized in a non-FreeBSD environment you can add
"MAKE?=make" somewhere around in PreComp/Makefile.am.
Btw this file has \r\n (dos) line endings...

There is still the more complicated issue with the file strings.h.
The problem is that FreeBSD's /usr/include/string.h does
#include <strings.h> which includes strings.h located in wxOil/
subdirectory instead of the system one (located in /usr/include) thus
resulting in a complete mess.
The workaround I have used so far is to prepend "-I../wxOil -I-" to the
compiler flags and to remove all occurrences of -I../wxOil after -I-

One possible solution would be to rename wxOil/strings.h to something
else - nonconflicting with the system headers.

Another possible solution I am currently looking at is whether it is
possible to force /usr/include/string.h not to #include strings.h,
string.h looks like this:
...
/*
 * Prototype functions which were historically defined in <string.h>, but
 * are required by POSIX to be prototyped in <strings.h>.
 */
#if __BSD_VISIBLE
#include <strings.h>
#endif
...

(__BSD_VISIBLE is defined by default)

-- 
Vasil Dimov
gro.DSBeerF@dv

Testing can show the presence of bugs, but not their absence.
                -- Edsger W. Dijkstra