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

[Todd Denniston]

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