Boost compilation problem

[Derek Atkins]

Christian Stimming <christian at cstimming.de> writes:

> Zitat von Derek Atkins <warlord at mit.edu>:
>> 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.

We can look at the SF pages and see that the 2.6.4 sources have been
downloaded about 500 times per week!  So I suspect that people are
definitely downloading the sources frequently, looks like 30-65 times
per day over the past week.

As for compiling boost from source, the question isn't whether they can,
but whether they can make it co-exist with the distributions' version.

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

You're assuming that I meant we should build 1.48 on current systems,
which is not what I'm suggesting.  We could (and probably should) just
perform the testing against minimum version on the target platforms
(arguably in a VM or chroot).

Honestly, just having some build slaves would solve this problem.

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

Yes, I agree.  But right now the only choice I see is whether to keep at
Debian stable or move to Debian testing (which does get us a small boost
in boost)  :)

> Regards,
>
> Christian

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available