[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Re: configure.in:305: error: possibly undefined macro: AM_GNU_GETTEXT
- From: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Tue, 06 Jun 2006 12:25:48 +0100
- Subject: Re: [XaraXtreme-dev] Re: configure.in:305: error: possibly undefined macro: AM_GNU_GETTEXT
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
+ $(MAKE) -C ../Kernel 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...
Unnecessary. Automake build files define $(MAKE), hopefully sensibly :-)
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.
On gcc we could fix this with -iquote wxOil instead of -I wxOil,
but that is not (I think) portable (e.g. I don't know if icc
In the old days we could fix this with -I-, but that is deprecated.
We should expect system headers to be able to include other system
headers successfully (which means they should go first on a -I
line), and I don't think there is any longer a non-deprecated
portable way to search for '#include "foo.h"' but not
'#include <foo.h>' - obviously this would be attractive.
So all said and done, I reckon we should probably rename strings.h to
camstring.h or similar as you suggest. I'm happy to do a rename. It's
actually only used in 32 places and at least 11 of them (probably many
more) are incorrect as it is in the pch.
Anyone object to me renaming this?