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

[al davis]

On Tuesday 27 February 2007 03:38, David Fang wrote:
>       I would call the issue a matter of global initialization
> ordering, not so much a link-order problem (bah, semantics!).

I really should use the proper words ..  sorry ...
"global initialization ordering"

>  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...

Actually the pointer approach brings on a potential problem with 
the order of destructors.  Pick one or the other.  It is likely 
you will not see a destruction order bug, but it is still 
there.

I understand this issue.  I am evaluating options.  There were 
no surprises so far.  I do consider it to be a bug, but not a 
serious one in comparison to other issues.

I still think making everything that moving everything that must 
be initialized later into a library and attaching it as a 
plugin is the best solution to the problem.  It is something I 
want to do anyway for other reasons.  The only problem 
remaining is that the "global initialization order" is still a 
potential problem on systems that require static linking and do 
not support any way to manually load modules at run time.

Another planned change is to move the dispatcher to become a 
static member of the base class.  This will provide a cleaner 
interface, but doesn't solve the initialization order issue.


>
> > > 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.

That doesn't work the same.  The %-style rule specifies 
dependencies and also how to do it.  The way you suggest only 
specifies how to do it.

I am aware that there are GNU make portability issues, and try 
not to use the extensions, but the only other way I know is to 
list all the files.  I am not an expert on make.
>
>
> 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

That is not the problem.  That tracks the .h dependencies, but 
still misses the .model dependencies.  

I still prefer the old way, which is "make depend" as a separate 
pass.  It is faster and cleaner, but leads to the possibility 
of forgetting to do "make depend" when it is needed.  That was 
standard procedure not too long ago.

I consider the mere existence of autogen.sh to be a bug.  Those 
updates should be tracked automatically by make.

I should be able to change any "Makefile.am" and recompile with 
just "make".  The inability to do this is a bug of fairly high 
priority.  I should also be able to change certain compiler 
options, including any "-D..." with just "make".

> 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

Just look at that ....   Things like that are among the "warts" 
that keep people on windoze.  The windoze people who don't know 
any better think a GUI is the solution.  That's what I mean 
when I say we need something better.

Spice is loaded with things like that.  Part of the purpose of 
gnucap is to get away from the junk in spice.


> 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.

There is work-around code in there, so it does work.  The 
problem before is that it had trouble with the first build, 
because with the autotools way the dependency table is built as 
a side effect of the first build.

But there is a point here ..  try this, try that, make a bigger 
mess, miss the obvious.  With complex tools it is easy to miss 
what an experienced user considers to be obvious.


Don't worry about these issues.  I plan to do some rearranging, 
which will completely change the build system.  I need to 
separate it ...  includes, core source, the reusable "ap" 
library, plugin groups: models, modeling functions, commands, 
languages, outputs, .....  Then look again.  Installation needs 
to change too.  Lots more stuff needs to be installed.

Probably the next development snapshot will use the old build 
system only, and the one after that bringing back an autotools 
based build system, still with the option of not using it.