Rob Browning <[EMAIL PROTECTED]> writes:
> 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.
Yes. The automake/autoconf way is to run configure once in each build
directory. From then on, you can just type "make" in that directory.
> 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...
By far the easiest approach is to use what automake gives me out of
the box. This a brute force "compile the whole thing in each tree"
scheme.
> > 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.
Okay, I've verified that the automatic dependency stuff works as it
does in gnucash now. It requires support from gcc and gnu make.
When you make a distribution (make dist), this dependency stuff gets
included in the Makefile.in. This removes the dependency on gcc and
gmake for the regular user. To turn it back on, the end user can just
run automake.
> > 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.
Agreed. I don't think I'll concentrate on this in the near term
though.
--
matt - http://www.lickey.com
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
