strangeness involving e2fsprogs header files

[Robert P. J. Day]

On Mon, 3 Jul 2006, Mike Frysinger wrote:

> On Monday 03 July 2006 07:53, Robert P. J. Day wrote:
> >   in my travels through the source code, i wandered across the
> > fact that a number of header file inclusions under e2fsprogs use
> > relative pathnames:
> >
> >   e2fsprogs/e2p/uuid.c:#include "../ext2fs/ext2_types.h"
> >   e2fsprogs/e2p/e2p.h:#include "../ext2fs/ext2_fs.h"
> >   e2fsprogs/blkid/read.c:#include "../uuid/uuid.h"
> >   e2fsprogs/ext2fs/mkjournal.c:#include "../e2p/e2p.h"
> >   e2fsprogs/ext2fs/mkjournal.c:#include "../e2fsck.h"
>
> this was done on purpose ... since the build system tends to be on
> the fragile side, using paths such as these:
>
> >   #include "ext2fs/ext2_types.h"
> >   #include "ext2fs/ext2_fs.h"
>
> is no good as they may pick up the standard e2fsprogs header files
> in /usr/include/ and it'd be a while before people noticed (or we'd
> get to chase down funky build errors)

oh, i realize what's happening here and why someone might want to do
it this way.  but if that's the case, then it's somewhat misleading
for e2fsprogs/Makefile.in to contain that snippet i reproduced
earlier:

...
# XXX: FIXME: change .c to include their stuff relative to $(E2FSPROGS_SRC)
E2FSPROGS_TMP_KLUDGE:=$(patsubst %,-I$(E2FSPROGS_SRC)/%,blkid e2fsck e2p ext2fs uuid)

APPLETS_DEFINE-y+=$(E2FSPROGS_CFLAGS) -I$(E2FSPROGS_SRC) $(E2FSPROGS_TMP_KLUDGE)
APPLETS_DEFINE-a+=$(E2FSPROGS_CFLAGS) -I$(E2FSPROGS_SRC) $(E2FSPROGS_TMP_KLUDGE)
...

whose sole purpose would *seem* to be to allow exactly what i was
talking about earlier, no?  one way or the other, something here
should be cleaned up to not be quite so misleading.

rday

p.s.  personally, my attitude toward "fragile" build systems is not to
accommodate them with unclean hacks, but to change the build system to
make it not so fragile in the first place.  i find it hard to believe
that no developer would want to clean up this feature because they're
afraid that they'll somehow break the build.  the last time i looked,
the ability to allow local header files to override system header
files of the same name was pretty much a solved problem.