Zitat von Derek Atkins <[email protected]>:
This works well because generally code that targets an older version of
a dependency will usually still work when compiled against a newer
version of that dependency. So if we target version 1.48 of libFoo it
will generally still work with version 1.50 of libFoo that another user
has.
Doing it this way makes it easy for users to build gnucash; they don't
have to figure out how to install "newer" dependencies on their systems.
That's the correct explanation of the thought process of how we chose
boost-1.48 as target. However, I see two issues here: Firstly, as
Aaron figured out, newer distros (with newer gcc's which have newer
warnings) won't even build with the old target boost anymore.
Secondly, I think we're overrating the fact that *users* might want to
*compile* gnucash for themselves and need to have it easy to do so. I
mean, this small minority of people who compile gnucash from source
can also be asked to compile boost from source. IMHO there's almost no
difference between the set of people who can compile gnucash from
source, and those who can compile both boost and gnucash from source.
I think we should still take the distro issue into consideration, but
can decide on a compromise between our developers' convenience (it's
us who do the work, anyway) and the dependency restrictions. In case
of boost, IMHO as Aaron told us, 1.48 doesn't even compile anymore
with current gcc and is therefore a nuisance to be used by us
developers. We should lift this up to some newer version, such as 1.52
or 1.56, whatever will be out on the market for 6-12 months at the
targeted stable release date. But I think any extra effort to get
boost-1.48 compile with our up-to-date build systems is rather wasted
and should better be invested somewhere else. Boost-1.52 plus/minus
one is my proposal.
Regards,
Christian
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
