Boost compilation problem

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Boost compilation problem

Aaron Laws
I asked on IRC and was told that our targeted boost version is 1.48. There
had been some minor dificulties with some of my commits recently because I
was using boost 1.56, so I thought it would be best to use the officially
targeted version. Now I'm using boost version 1.48 (from boost version
control), and the project doesn't compile using it due to a bug in boost
that produces a narrowing warning. We treat that warning as an error.

The fact that our gnucash/trunk doesn't compile under the targeted boost
version suggests that nobody's using that version. The reason I've heard
for why we target an old version is because Debian stable has this version
in their repo. I surmise that the thought process is something like: most
people who might want to compile gnucash will use Debian to do so, or
something along those lines. I also surmise, since the project doesn't work
with boost 1.48, that nobody's doing that.

I have two concerns: 1) We should seriously consider what version of boost
we target, and 2) I would like to be able to compile the project again :-)

1) doesn't mean that we should change our boost target, but that we should
*use* it for development and production! If we target version 1.48, and I
develop with 1.56 and commit, and we ship based on 1.52, we're asking for
trouble.

Personally, I recommend targetting 1.56 for the following reasons: It is
the most mature, it is the first version of boost using their git repo,
people familiar with cutting-edge Boost will be at home, you won't find
yourself reading "too modern" documentation when researchng Boost.
Answering objections: it's *dead* simple to build...like two commands! It
takes a bit, but very, very simple.

I don't really care which version we use, but I am quite convinced about
picking some version and *using* it.

2) I'm not good enough with autotools to figure out how to add
-Wno-error=narrowing (or whatever needs to happen here) to my particular TU
(src/lib-qof/qof/guid.cpp), any suggestions?

Thanks!

In Christ,
Aaron Laws
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Boost compilation problem

Derek Atkins
Hi,

Aaron Laws <[hidden email]> writes:

> I asked on IRC and was told that our targeted boost version is 1.48. There
> had been some minor dificulties with some of my commits recently because I
> was using boost 1.56, so I thought it would be best to use the officially
> targeted version. Now I'm using boost version 1.48 (from boost version
> control), and the project doesn't compile using it due to a bug in boost
> that produces a narrowing warning. We treat that warning as an error.
>
> The fact that our gnucash/trunk doesn't compile under the targeted boost
> version suggests that nobody's using that version. The reason I've heard
> for why we target an old version is because Debian stable has this version
> in their repo. I surmise that the thought process is something like: most
> people who might want to compile gnucash will use Debian to do so, or
> something along those lines. I also surmise, since the project doesn't work
> with boost 1.48, that nobody's doing that.

No, the thought process is "when we release gnucash we want users to be
able to build gnucash using the dependencies provided by their
distribution."  To that end, we figure out what versions of our
dependencies are available on each of the distributions about 6-12
months before our target release date and then choose the oldest version
out there.  This way when gnucash gets released it should work for the
vast majority of users.

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.

> I have two concerns: 1) We should seriously consider what version of boost
> we target, and 2) I would like to be able to compile the project again :-)

Yes, we should consider what version of boost (and indeed any
dependency) we target as the "minimum" version.  We generally do this
based on what's out there in the released world.

> 1) doesn't mean that we should change our boost target, but that we should
> *use* it for development and production! If we target version 1.48, and I
> develop with 1.56 and commit, and we ship based on 1.52, we're asking for
> trouble.

Yes, this is true.  We definitely need to be testing against our minimum
version.

> Personally, I recommend targetting 1.56 for the following reasons: It is
> the most mature, it is the first version of boost using their git repo,
> people familiar with cutting-edge Boost will be at home, you won't find
> yourself reading "too modern" documentation when researchng Boost.
> Answering objections: it's *dead* simple to build...like two commands! It
> takes a bit, but very, very simple.

Nope, this is a no-go.  For example Fedora 20 (a current release) only
ships with 1.54.

> I don't really care which version we use, but I am quite convinced about
> picking some version and *using* it.
>
> 2) I'm not good enough with autotools to figure out how to add
> -Wno-error=narrowing (or whatever needs to happen here) to my particular TU
> (src/lib-qof/qof/guid.cpp), any suggestions?
>
> Thanks!
>
> In Christ,
> Aaron Laws

In Moses,

> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

-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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Boost compilation problem

Christian Stimming-4

Zitat von Derek Atkins <[hidden email]>:
> 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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Boost compilation problem

Derek Atkins
Christian Stimming <[hidden email]> writes:

> Zitat von Derek Atkins <[hidden email]>:
>> 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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Boost compilation problem

Aaron Laws
On Fri, Oct 24, 2014 at 11:10 AM, Derek Atkins <[hidden email]> wrote:

>
> 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.
>
>
Just to be clear, if I'm understanding correctly, this is done by building
boost with ./bootstrap --prefix=/home/derek/boostbuild; , and when building
gnucash, ./configure --with-booth=/home/derek/boostbuild; I hope that
clears up that point sufficiently.

In Christ,
Aaron
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Boost compilation problem

John Ralls-2
In reply to this post by Derek Atkins

> On Oct 24, 2014, at 8:10 AM, Derek Atkins <[hidden email]> wrote:
>
> Christian Stimming <[hidden email]> writes:
>
>> Zitat von Derek Atkins <[hidden email]>:
>>> 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).

First off, Debian Stable is at Boost 1.49, not 1.48, and Gnucash master built just fine on it yesterday.
>
> 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)  :)

Actually it gives a big boost: To 1.55. F20 and OpenSuSE are on 1.54, Gentoo has 1.56 (current).

I'm inclined to set it to 1.49 for now and 1.54 when we get around to needing some of the newer libraries. Depending on what gets added or improved in the next 2 years we may want to raise it again before we start the 2.7 testing cycle.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Boost compilation problem

ChrisGood
In reply to this post by Aaron Laws
Nice one Derek :-)

Sorry Aaron, while I don't have a problem with you believing something different to me, it is annoying to be subjected to your personal beliefs on every email from you.

Regards,

Chris Good

> On 25 Oct 2014, at 3:00 am, [hidden email] wrote:
>
> Send gnucash-devel mailing list submissions to
>> !
>>
>> In Christ,
>> Aaron Laws
>
> In Moses,
>
>> gnucash-devel mailing list
>> [hidden email]
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel