Matt Armstrong <[EMAIL PROTECTED]> writes:
> I am sure that with the proper amount of effort the current scheme
> could be kept and improved to the point where it satisfies my
> desires. When you typed "make gnome" it would say "could not find
> guile" or whatever.
I don't really care about being able to do both "make gnome" and "make
motif" from the same directory. That's not the critical bit. All I
really want is the ability to build both gnome and motif versions from
the same source tree without having to re-run configure (or clobber
the existing object files) between builds.
Right now we get that by compiling into ./obj/foo.o for common files
and ./obj/<ui>/foo.o for ui specific files. It strikes me, though,
that this could just be recast as roughly similar to an "architecture
dependence" issue which automake might already know how to handle
well. It's fine with me if you have to make it so that you have to
have separate build directories (but still one source directory).
This could be somewhat wasteful (in terms of space) if you have to
have the ui independent files compiled in each build dir (instead of
sharing them). I'm not sure how bad that might be, or how you might
make it possible to keep sharing the ui independent files. It's worth
thinking about. It might be worth a doing a little source tree
restructuring to create a stronger separation between common code and
ui-dependent code. If the independent code is set up as completely
separate modules, then you may be able to build it separately and use
symlinks or whatever to provide the ui-independent bits to all the
ui-dependent build-trees. I'm not familiar enough with automake to
know. It may be obvious what's the easiest/cleanest way to handle
this once you get going...
If you structure the top level makefile right, even in the separate
build dir setup, you could probably still support "make <ui>" as the
way to get things started, but as I said, that's not really critical
to me.
> I'll look into it more. The makefiles automake generates create
> dependency info the same way gnucash does. I think gnucash's method
> depends on gcc too.
Right, it does, but I'd just like to make sure we maintain the current
strategy that re-builds the dependency files as part of every
compilation command rather than changing to a strategy that requires a
separate "make depend" step (or separate invocation of gcc). The
latter strategy is just asking for stale dependencies and is much less
efficient.
> src/engine is compiled with -fpic so, according to the comments, it
> can be put into things like perl modules. Are there any examples of
> where this has been done?
Yes, I've played with that in the past. I had it so that you could
just say "use gnucash;" or whatever, and perl would dynamically link
in an engine.so file. I don't know if that's still lying around or
not.
What we really should do is have the engine build as both a .so and .a
file so you can use whichever you need. To do that, it might be best
to just start using libtool (which automake knows about in detail).
This will also make our shared lib stuff fairly substantially
cross-platform.
There are some issues with libtool trying to be too smart for it's own
good (which Debian has been trying to work out with the author(s) for
a while), but that shouldn't affect individuals building gnucash, and
Debian (and other packagers like RedHat) have a well-established
workaround for the problem (presuming it hasn't been fixed yet).
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
