[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

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



Vasil,

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 ---

Applied (thanks).

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
supports it).

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?

Alex