Hija,

I'm throwing the following fix for consideration. The problem is that by standard headers are looked for in various locations under the srcdir, however there're also header files which are automatically generated and (rightfully) put into objdir but are not searched for there. This breaks builds where srcdir != objdir.

My simple fix is to add another include search path relative to the current directory (i.e. objdir) where needed. I realize that there might be better ways to fix that which I currently can not see so I'm posting it here with a RFC.

Index: app/display/Makefile.am =================================================================== RCS file: /cvs/gnome/gimp/app/display/Makefile.am,v retrieving revision 1.42
diff -u -r1.42 Makefile.am
--- app/display/Makefile.am 13 Feb 2005 15:08:04 -0000 1.42 +++ app/display/Makefile.am 26 Feb 2005 17:10:39 -0000 @@ -75,6 +75,7 @@
INCLUDES = \
-I$(top_srcdir) \
-I$(top_srcdir)/app \
+ -I.. \
$(GTK_CFLAGS) \
-I$(includedir)

Index: app/tools/Makefile.am =================================================================== RCS file: /cvs/gnome/gimp/app/tools/Makefile.am,v retrieving revision 1.88
diff -u -r1.88 Makefile.am
--- app/tools/Makefile.am 13 Feb 2005 15:08:07 -0000 1.88 +++ app/tools/Makefile.am 26 Feb 2005 17:10:39 -0000 @@ -157,6 +157,7 @@
INCLUDES = \
-I$(top_srcdir) \
-I$(top_srcdir)/app \
+ -I.. \
$(GTK_CFLAGS) \
-I$(includedir)

Index: app/vectors/Makefile.am =================================================================== RCS file: /cvs/gnome/gimp/app/vectors/Makefile.am,v retrieving revision 1.16
diff -u -r1.16 Makefile.am
--- app/vectors/Makefile.am 13 Feb 2005 15:08:07 -0000 1.16 +++ app/vectors/Makefile.am 26 Feb 2005 17:10:40 -0000 @@ -7,6 +7,7 @@
INCLUDES = \
-I$(top_srcdir) \
-I$(top_srcdir)/app \
+ -I.. \
$(GDK_PIXBUF_CFLAGS) \
$(LIBART_CFLAGS) \
-I$(includedir)

Servus, Daniel

On 26.02.2005, at 20:23, Sven Neumann wrote:

Looks like the wrong fix to me. Instead we should change the Makefiles to look for the generated files in the right spot (and .. isn't the right spot).

Actually .. is the right spot since make is moving in and out of the objdir. However I can see why you would prefer an obsolute path, that's why I was asking this question.

Anyway, libtool is using objdir for it's internal object management which is for instance some .libs directory on Linux machines, so we can pretty much forget about using this. Instead we'd need a new variable into the game and the closest I can think of is far nastier than three relative paths which at least won't require major surgery.

Servus, Daniel

On 26.02.2005, at 23:44, Sven Neumann wrote:

Anyway, libtool is using objdir for it's internal object management which is for instance some .libs directory on Linux machines, so we can pretty much forget about using this. Instead we'd need a new variable into the game and the closest I can think of is far nastier than three relative paths which at least won't require major surgery.

What's wrong with $(top_builddir)?

Maybe nothing, except that I didn't see it before.

Would a patch like the former but with absolute paths instead of the relative ones be okay for CVS after a verification build?

BTW, the problems you are seeing only apply to builds from CVS. The tarball has all the generated source files, so everything is where the Makefiles are looking for it. It appears though that we do indeed require to build a CVS checkout in the srcdir.

Indeed, however not having to clutter the srcdir with generated files and other cruft is a big must-have in my book especially while developing, so I'm sort of confused that this hasn't shown up earlier...

How can I get the stuff pre-built so that this is supposed to work?

Besides, there're some checks missing in configure for applications which are really needed to build from CVS, like intltool and xsltproc. Especially for the latter it's really annoying that I can get through configure just fine but in menus/ the Makefile will bail out because xsltproc is desperately needed, so I need to install it and rerun configure to get rid of the problem; not the finest English...

Servus, Daniel

On 26.02.2005, at 23:44, Sven Neumann wrote:

What's wrong with $(top_builddir)?

Ho hum. That's a relative path as well, so instead of -I.. that would be -I$(top_builddir)/app which gets expanded to -I../../app . We could do that but I don't really see the big advantage instead of just using my originally proposed patch.

Servus, Daniel

On 26.02.2005, at 23:44, Sven Neumann wrote:

BTW, the problems you are seeing only apply to builds from CVS. The tarball has all the generated source files, so everything is where the Makefiles are looking for it. It appears though that we do indeed require to build a CVS checkout in the srcdir.

Another thing's fishy wrt the generated C files. For some reason make will bail out on any of them because they're being generated in the wrong place, however if I restart make often enough it will eventually pick up the correct files and compile them....

Servus, Daniel

On 27.02.2005, at 01:14, Sven Neumann wrote:

We would probably have to add this to all Makefile.am in the app subdirs then?!

Only to those containing sources which refer to automatically generated headers, about 3 or 4.

There are .cvsignore files that cover these files. Building in the srcdir is common practice and I don't see anything wrong with it.

Well, noone stops you from doing this but that's not clean or even superior.

Usually the srcdir != builddir only shows up when people are building packages.

Err, no. For one I really don't like having to backup wasted sources and bandwidth is not plenty here to refetch from scratch or some random point in the past.

Second, many people (including me) like to build for several architectures from one sourcebase. In case of GIMP it's only four for me (i386, x86_64, ppc linux, ppc OS X) but there are others where I do some more (ARM linux, mipsel linux, ppc linux uclibc, mipsel linux uclibc, ARM linux uclibc) and in case of compilers even crosscompilers and stuff. It's really hard to imagine having to clone something like the gcc sources several times to build in the source directory, leave alone keeping all of them up-to-date....

Building packages is one possible use for this, but since typically at least the sources and the closer environment are rebuilt per try it doesn't matter whether one builts in the source or not; what matters more there is DESTDIR capability....

There are checks for these tools in autogen.sh and you are supposed to run this (and you are supposed to read HACKING even if you think you don't need autogen.sh).

Of course I ran autogen.sh, however I did *not* run it per target as this makes the whole point of seperating srcdir and objdir moot...

Especially for the latter it's really annoying that I can get through configure just fine but in menus/ the Makefile will bail out because xsltproc is desperately needed, so I need to install it and rerun configure to get rid of the problem; not the finest English...

The tarball can be built w/o these tools and we don't want it to depend on them. So it would be wrong to move these checks into configure. Our english is actually rather carefully chosen...

So what do I have to do to make the sources self-contained?

Servus, Daniel

On 27.02.2005, at 02:50, Manish Singh wrote:

We should do -I$(top_builddir)/app. This avoids needing to care about how deep the directory is, in case the directory is moved elsewhere.

But that's still not the cure for all possible problems that may arise by moving the header (e.g. from app to libfoo). Anyway, that's better than nothing...

Servus, Daniel

On 27.02.2005, at 02:55, Manish Singh wrote:

Only to those containing sources which refer to automatically generated headers, about 3 or 4.

No, we should add it to all of them.

Agreed. Consistency is good.

In fact, it already *is* in some of them.

So here's what I'm currently doing. I took the 4 lines block -I$(top_builddir)
-I$(top_srcdir)
-I$(top_builddir)/app
-I$(top_srcdir)/app
and put it into all app/*/Makefile.am instead of their incomplete or shuffled variants. This makes the include paths consistent across all subdirectories and hopefully take care of all problems without causing sideeffects. I'm compiling with those changes right now.

./autogen.sh on one system, make dist it, and unpack and build from your
disted tarball for the rest of your builds.

Cool, I've been searching for a target "release" or something but couldn't find it... ;)

Or just do your due
diligence and be consistent about all your dependencies on the targets you build on.

This is impossible for various reasons. One being that auto* like to link into the filesystem which would need identical directory and installation setups on all, likely very different, systems, (e.g. Linux and OS X). Another being that different devices have different capabilities and for instance no graphical output or run Gtk+2 on a different backend like Windows or DirectFB.

Which brings me to the next problem I'm facing on x86_64 Linux: the screenshot plugin fails to link because it tries to -lX11 directly which for some reason cannot be found because the library path seems to be incomplete at the point of reference...

Servus, Daniel

On 27.02.2005, at 03:09, Manish Singh wrote:

But that's still not the cure for all possible problems that may arise by moving the header (e.g. from app to libfoo). Anyway, that's better than nothing...

There's no getting around updating the Makefile.am for that. With your naive solution, it *adds* a reason.

Your wisdom is hard to grok at times but since we're obviously on the same page I'll go ahead and implement your solution I sought after.

Servus,
Daniel