Matt Armstrong <[EMAIL PROTECTED]> writes:
> It is not an improvement as long as all the different make
> configurations require the same things from the build environment.
>
> But that isn't the case with GnuCash. "make gnome" needs to link
> with gnome libraries and "make motif" needs motif libraries, etc.
>
> Once you get into this kind of situation, configure can no longer
> insist on finding all the libraries and header files it needs (since
> configure can't know what will be needed).
Ahh. I'm so used to building both, I hadn't really thought about
that. I guess you could have it enable whichever targets in the
makefile whose dependencies are satisfied, but that's getting messy.
> Traditionally autoconf'd packages solve this problem by requiring
> the developer to use a VPATH capable make program (usually gmake) to
> find the source in a separate dir from the build tree. This allows
> to ./configure in multiple build directories from the same source
> tree simultaneously.
>
> In your motif build dir, you'd run "../gnucash/configure
> --use-motif" and in your gnome build dir, you'd run
> "../gnucash/configure --use-gnome." The build dirs wouldn't have
> any source in them.
>
> This is how emacs, gdb, gcc, zsh, etc. choose between major bits of
> functionality (toolkit used, target and host architecture,
> dynamically or statically built, etc.).
This makes sense. I'm not tremendously familiar with this approach,
but I'm sure we'd be happy to accept patches that make this happen.
Actually, in any future projects I start, I'm planning to use cons
(http://www.perl.com/CPAN-local/authors/Bob_Sidebotham/cons_1.1.tar.gz).
I want to see how well it works. If it lives up to even half of what
it promises in the documentation, it would be a far superior tool to
make, and would fit right in with autoconf, etc.
I'd be willing to take the time to migrate GnuCash to cons, but I'm
not going to. I imagine others would (rightfully) be opposed to yet
another dependency. Although, since it's a perl module, it's likely
to be a lot more portable (and easier to install) than some of the
other things we've required.
> > However, I do agree that things should be strucured so that
> > configure outright fails when it can't find something it needs.
> > Wherever it doesn't, I consider that a bug.
>
> I agree. To reach this goal, you need to specify at ./configure time
> any build parameters that affect the libraries or headers the source
> will require. Otherwise, configure can't insist upon thier presence.
>
> If we reach a consensus on how to beef up the configure/make system to
> be friendlier to first time compilers, I'm willing to work on it. I
> think it is important to lower GnuCash's "compile barrier."
This is certainly true, and the help would definitely be welcome.
Before you go too nuts though, wait for my next patch that adds the
new guile stuff.
To tell the truth, in the long run, I'd be happy to greatly simplify
things by just dropping the Motif version, but that can't happen until
the GNOME version makes *substantial* progress.
--
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
