Re: Mixing BUILT_SOURCES, double quote include and separation of source and binary directory

[Ralf Wildenhues]

* Simon Perreault wrote on Wed, Mar 30, 2005 at 06:13:19PM CEST:
> On March 30, 2005 10:44, Ralf Wildenhues wrote:
> > > #include "../include/inc.h"
> >
> > which is not portable, by the way (but I can see if you don't care about
> > that part of the world).
> 
> Why do you say that? That code is being ported from Microsoft's compiler, and 
> I guess that if it works there and here then it ought to be portable.

IIRC some older compilers on Windows did not understand `/'.
Plus, I would consider using `..' and `include' in the actual path to be
bad style (not directory entries in general -- it's good to have
 ../include/foolib/foo1.h and use #include "foolib/foo1.h").

> > If you put this rule in several directories, it might lead to race
> > conditions with parallel make.  (Your example suggests you might be
> > doing this.)
> 
> Do you mean that if many make jobs try to make the same directory at the same 
> time it will fail? I don't think so, since creating a directory is atomic and 
> mkdir -p shouldn't fail if the directory is already created. But if mkdir is 
> broken and fails because the directory was created between the time it 
> checked for its existence and the time it tried to create it, then mkdir is 
> broken and should be fixed. Anyway, that's off topic.

Well, using $(mkdir_p) fixes the `mkdir -p' part.  But your header
creation might
- not be atomic, e.g.  echo line1 > $@; echo line2 > $@
- not be allowed to be executed in parallel
(I *really* don't know whether parallel make works on cygwin.  But
redirection into a file held open by another process fails there.)

> > - change the rule above to create a symlink to the current directory
> >   or a central directory, for that matter
> >   (be sure to look at $(LN_S) semantics in the Autoconf docs!).
> >   Have `make clean' remove the links.
> 
> Sorry, I don't understand your solution. Does that mean I should modify all 
> the files including the built headers so that they point to the central 
> directory?

No, why?  Automake puts `-I.' in AM_CPPFLAGS.  After you ensure that
 ../include/built.h exists, you have in Makefile.am

BUILT_SOURCES = built.h
built.h: ../include/built.h
        rm -f $@ && $(LN_S) ../include/built.h $@

or easier, you have in the Makefile.am one level higher up:

BUILT_SOURCES = include/built.h
include/built.h:
        $(mkdir_p) include
        touch $@
        for srcdir in $(some_dirs); do \
          cd $$srcdir && { rm -f built.h; $(LN_S) ../include/built.h .; }; \
        done

I'd probably extend that rule so that its output has modification times
updated only when necessary (look at `move-if-change').  Plus update
CLEANFILES and/or clean-local.

> If so, then I can't do that since the code I'm working on has to 
> keep working on another build system.

SCons?  :)

> If not, then can you explain a bit more?

HTH,
Ralf