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 [EMAIL PROTECTED] ; \ > 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 [EMAIL PROTECTED]; f=`basename $@ .h`.fl; \ h=`basename [EMAIL PROTECTED]; \ 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