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

["Gerry Iles" <GerryI@xxxxxxxx>]

I'm not objecting to the rename but it might be better to "fix" the
issues with the setting of the various variables (CPPFLAGS, CXXFLAGS,
AM_ etc) so that the build commands have the -I's in the correct order
(and also don't duplicate lots of the settings, e.g. same stuff is put
in CPPFLAGS and CXXFLAGS which is incorrect).

Gerry

-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Alex Bligh
Sent: 06 June 2006 12:26
To: vd@xxxxxxxxxxx
Cc: dev@xxxxxxxxxxxxxx; Alex Bligh
Subject: 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