Re: [Gnucap-devel] missing info in the models tarballs.

[David Fang]

> > Since you intend for model-writers to plug-in/link against
> > gnucap, you could try to simplify things by propagating
> > linker flags (the same used in building gnucap) to a
> > configuration file.  The flags contain more than the usual
> > paths, but also some flags deduced by libtool, if you're
> > making some libtool-like assistance to model-compilation.
> > (Is this what you had in mind about 'libtool-light'?)  It
> > could be a piece of boilerplate Makefile that can be included
> > by plugins' Makefiles.
> > e.g. "include /usr/local/lib/gnucap/mk/modelgen.mk"
> > (/lib instead of /share, because it will be
> > architecture-dependent) This way, no additional configuration
> > is necessary for the plug-in build, just re-using the results
> > of the core's configuration.
>
> Yes,
>
> Most plugins, models, etc will be single files.  If you want to
> load several as a group, it is permissible to link them into a
> single file.
>
> I also want it to be possible to build a custom static linked
> version, just by listing the modules they want in a Makefile.
> This is why the link order issue came up.  I could solve the
> whole link order problem by requiring all that can be plugins
> to really be plugins.

Hi Al,
        I would call the issue a matter of global initialization ordering,
not so much a link-order problem (bah, semantics!).  Did you rewrite the
dispatch maps to initialize more robustly?  Because attacking the link
order of the translation units (with any amount of configury) isn't
getting to the heart of the problem.  It sounded like you were on the
right track before, going with initializing a map pointer once...

> > Requiring a C++ compiler is not a big deal.  Can you
> > summarize why the .model files were a headache?  (The mail
> > archive I'm reading through lumps all messages with the same
> > subject "new gnucap development snapshot" into the same
> > thread, which mixes things up incoherently...)
>
> Dan McMahill did the autoconf work.  (Thank you Dan,  It helped
> a lot!!)

Props, Dan!

> Basically what happens is ...
>
> First, the program "gnucap-modelgen" must be built, because it
> is needed to compile the .model files.
>
> The ".model" files are compiled by "gnucap-modelgen" to create
> a ".cc" and a ".h" file. (or an equivalent combined file).
>
> This .cc file is compiled.

Looks that way indeed, with the recursive make, modelgen's dir appears
before src/ so the directory order is correct.  modelgen is guaranteed to
be finished before it is used in the builddir.

> The problem is with automatic dependency tracking.  With a
> standard Makefile, a simple pair of rules seems to take care of
> it:
> #------------------------------------------------------------------------
> %.cc : %.model gnucap-modelgen
>       ./gnucap-modelgen -cc $<
> #------------------------------------------------------------------------
> %.h : %.model gnucap-modelgen
>       ./gnucap-modelgen -h $<
> #-----------------------------------------------------------------------------

Something doesn't look right in your src/Makefile.am: You declare .model
as a SUFFIX, but you use %-style rules, which don't follow suffix rules
[1].  When I build sources, I do the following (using your example) in
Makefile.am:

------------>8 snip 8<------------
SUFFIXES = .model .cc .h

.model.cc:
        ${MODELGEN} -cc $<

.model.h:
        ${MODELGEN_EXE} -h $<

$(MODELSRCS): $(MODELGEN)
------------>8 snip 8<------------

[1] As a matter of taste, I never use %-style rules for the sake of
portability, it's GNU make only.  No biggie though, GNU make is free and
virtually ubiquitous.


To force modelsrcs to be built as early as possible, you can also declare:
BUILT_SOURCES = $(MODELSRCS)
but it's not necessary in this case, since dependencies are specified.

But this doesn't address the missing header dependencies.
After hunting around, I found this in your autogen.sh:

automake -a -c --gnu --ignore-deps || exit 1

--ignore-deps DISABLES dependency tracking features... *AHEM*
Don't blame the tools, you asked for it!  :P
No wonder my efforts to automake couldn't find the depcomp script...
Remove that flag, re-autogen, and try again, and magically .deps/ will
appear in your build directories.  Dependencies are dynamically
tracked, computed as side-effects of compilation.  e.g.:

if g++ -DHAVE_CONFIG_H -I. -I../../src -I..   -DNDEBUG  -g -O2 -MT
d_coil.o -MD -MP -MF ".deps/d_coil.Tpo" -c -o d_coil.o
../../src/d_coil.cc; \
then mv -f ".deps/d_coil.Tpo" ".deps/d_coil.Po"; else rm -f
".deps/d_coil.Tpo"; exit 1; fi


> Even with the same rules, the autoconf version seems to not
> track the dependency properly.  The idea is that changing
> a .model, and Make does the right thing.  It is further
> complicated because the modeling language supports inheritance,
> so generated .h files are used in other .cc files in addition
> to their own.

Getting autotools mixed up again, dependencies have little or nothing to
to with autoconf, autoconf's (configure) job is to detect the style of
dependency, and honor the user's overriding request.  See above solution
to enable.

> The autoconf version builds in a different order ..  It does all
> the modelgen work before any c++ work.  The old system defers
> running modelgen until the resulting .cc and .h are needed.
> This in itself is not a problem, but is an indicator that
> something isn't right.  For now, there is a workaround that
> builds them all when you touch any of them.  This is safe, but
> causes unneeded recompiles.
>
> Neither Dan nor I could figure out a better way that worked.

Again, late is the hour, I'll respond to the rest of the message after a
night's rest.  Do try enabling dependencies and test them out: touch a
header file and re-make, etc.

I'm out.... *thud*

David

----------->8 big snip 8<-----------------


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
        -- (2400 baud? Netscape 3.0?? lynx??? No problem!)