Re: How to use BUILT_SOURCES in non-recursive, multi-directory project?

[Ralf Wildenhues]

Hi Duncan,

Note: I don't know whether and how much of this was already addressed.

* Duncan Gibson wrote on Sat, Mar 04, 2006 at 06:09:22PM CET:
> 
>     use 'fluid -c foo.fl' to create foo.h and foo.cxx
>     create libfoo.a from foo.cxx
>     compile foo_test.cxx and link against libfoo.a

*snip*
> The src/Makefile.am looks like:
> 
>     bin_PROGRAMS += src/foo_test
>     noinst_LIBRARIES += src/libfoo.a
> 
>     AM_CPPFLAGS = -I$(srcdir)/src -I$(top_builddir)/src $(FLTK_CXXFLAGS)
> 
>     .fl.h:
>             d=`dirname address@hidden ; \
>             f=`basename $@ .h`.fl ; \
>             cp $< $(top_builddir)/$$d/$$f ; \
>             cd $(top_builddir)/$$d ; \
>             fluid -c $$f
> 
>     BUILT_SOURCES += src/foo.h
> 
>     nodist_src_libfoo_a_SOURCES = src/foo.cxx
> 
>     src_foo_test_LDADD = src/libfoo.a $(FLTK_LIBRARYS)
>     src_foo_test_LDFLAGS = $(FLTK_LDSFLAGS)
>     src_foo_test_SOURCES = src/foo_test.cxx
> 
> After a lot of trial and error, the src/Makefile.am *appears* to work,
> but I'm concerned about the filename manipulations in the .fl.h rule,

dirname and basename are not portable to ancient hosts.  In practice
they will work fine, though.  I'd write

            cp $< $(top_builddir)/$$d/$$f && \
            cd $(top_builddir)/$$d && \
            fluid -c $$f

so that you get failures if something fails.  But even then this
construction is not really safe: Automake will put
  VPATH = @srcdir@

in your Makefile.in.  And the fact that after the first build you have
two copies of the source will confuse `make': it may look at the wrong
one and decide nothing needs updating, when in fact it would need to.

I'm not totally sure how to go about this.  Can't the `fluid' program be
taught to accept input files with a path and still output in the current
directory?  That's what I'd expect from a halfway sane tool even if the
output file can't be specified.

I guess you could use symlinking instead of copying to work around this
limitation.  Take a look at Autoconf's AC_PROG_LN_S description and use
$(LN_S) to at least fix this on all systems where sym- or hardlinking
works.  Oh, that complicates it: you'd need to know the
relative-or-absolute path starting from the output directory.. :-/

> the lack of checking so that I don't zap things if building in $(srcdir),

Ahh, right.  There should probably be a
  test "$(srcdir)" != .

guarding the copy.  I usually don't care that users get busted if they
enter this in the top level source directory:
  `pwd`/configure
instead of this:
  ./configure

I guess we end up with something like this then (untested):

 .fl.h:
        d=`dirname address@hidden; f=`basename $@ .h`.fl;          \
        h=`basename address@hidden;                                \
        cd $$d && test "$(srcdir)" != . && {            \
          $(LN_S) $(abs_top_srcdir)/$$d/$$h $$f ||      \
          rm -f $$f;                                    \
        } && fluid -c $$f

The absolute path is ugly, but I don't know a better way off-hand, given
the LN_S restrictions.  You may need to AC_SUBST abs_top_srcdir in
configure.ac (not sure).

> AM_CPPFLAGS needing both $(srcdir) and $(top_builddir),

That's quite normal.

> the fact that src/foo.fl doesn't appear anywhere,

Oh.  It should probably be listed in EXTRA_DIST so that it gets
distributed, I guess.

No I get to wait and see if I get corrected.  :-)

Cheers,
Ralf