[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ralf Wildenhues
Subject: Re: How to use BUILT_SOURCES in non-recursive, multi-directory project?
Date: Thu, 9 Mar 2006 19:13:33 +0100
User-agent: Mutt/1.5.9i

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

> The src/ 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/ *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  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:
instead of this:

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

        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 (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.  :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]