[XForms] Getting rid of auto-generated files...

Todd Denniston Todd.Denniston at ssa.crane.navy.mil
Wed Nov 26 09:21:47 EST 2003

Angus Leeming wrote:
> To subscribers of the xforms list
>   ------------------------------------------------------------------------
> On Monday 24 November 2003 7:51 pm, Angus Leeming wrote:
> > To subscribers of the xforms list
> >
> >
> > It would be nice if we could get rid of at least some of the .[ch] files
> > generated from .fd datasets.
> >
> > We store .fd files and their associated .[ch] files in the following
> > directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these,
> > the .[ch] files in the first two directories would have to remain. (We
> > cannot generate the .[ch] files until fdesign has bee created.) However, it
> > strikes me that the .[ch] files in the remaining directories could all be
> > generated on the fly, just as we do in LyX.
> >
> > Personally, I think that this would be much more elegant. Thoughts?
> Ok, I'm stuck ;-)
> Jean-Marc, I wonder if you might help... Attached are the changes I've made to
> demos/Makefile.am. This is proof of concept code and, indeed, works fine.
> However, I have no idea how to turn it into robust code :-(
> The problem lies with the block below which generates .[ch] files from  a .fd
> file. Note that I am running this conversion from $build_dir/demos whilst the
> .fd file is to be found in $srcdir/demos/fd. Note the extra '/fd' there. I do
> not want to generate a static library in the fd directory because I want to
> be able to build individual demo files if I so choose.
> Here's the troublesome (but working) block:
> %.c: %.fd ../fdesign/fdesign
>        (cd `dirname $<` && /home/angus/xforms/cvs/build/fdesign/fdesign
> -convert `basename $<`; \
>        mv `basename $< .fd`.[ch] /home/angus/xforms/cvs/build/demos/fd/.)
> Line 1. All is Ok. The generated .c file depends on the .fd file and on the
> existence of the fdesign binary.
> %.c: %.fd ../fdesign/fdesign
> Lines 2,3. The problems. It appears that fdesign must be run from the
> directory containing the .fd file. That means I lose track of the fdesign
> binary and then must move the generated .[ch] files into the $builddir tree
> (if $srcdir != $builddir).
> Any ideas?
> Angus
Actually, fdesign does not need to be ran from the directory containing
the .fd file.
You can pass it the path to the .fd, as in `fdesign -convert $<`,
however fdesign as built now will make the .[ch] files in the same
directory as the .fd file.

perhaps you can/should use the gnu-make extension of vpath's, i.e., have
the following added to the beginning of the demo's directory Makefile:

vpath %.h .
vpath %.c .
vpath %.h ./fd
vpath %.c ./fd
vpath %.fd ./fd

at least when vpath is available.

a fallback, for non gnu makes, might be to make a rule that causes a `cp
-p *.fd .` to occur if any file is newer in the fd directory than say
the 'fdscopied' file, i.e., make fdscopied depend on all .fd files in
the fd directory.  Ugly but I am pretty sure I have used it in the past
with other recalcitrant programs.

At a later time it would be nice to have an option to pass to fdesign to
either force it to output in the current working directory, or another
specified output directory.

Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter

More information about the Xforms mailing list