polybori spkg compilation

[Timo Kluck]

Hi,

I'm hoping a polybori expert can quickly spot the difference between two builds I'm doing of the spkg. I'm looking into how difficult it would be to wrap the spkg system by Gentoo's portage for dependency resolution. (Hint: it doesn't seem to be extremely difficult, this is the only thing I'm running into.) The normal `sage -i` of the spkg succeeds, but my emerge build fails. There's probably a subtle difference in the environment that I have difficulty spotting. Maybe someone who is familiar with polybori can easily tell what's going on?

I have the build log for the usual `sage -i polybori-0.8.2.p0.spkg` and also a build log for `emerge legacy_spkg/polybori`. The latter's build instructions are just `sage -sh -c ./spkg-install`. The logfiles are almost identical up until the end:

g++ -o testsuite/src/BlockDegLexOrderTest.o -c -Wno-long-long -O2 -pipe -std=c++98 -ftemplate-depth-100 -O3 -Wreturn-type -mmmx -msse -msse2 -msse3 -DPBORI_NDEBUG -DSIZEOF_VOID_P=8 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DPBORI_HAVE_TR1_UNORDERED_MAP -DPBORI_HAVE_M4RI -DPBORI_HAVE_M4RI_PNG -Ilibpolybori/include -Igroebner/include -I/home/tkluck/src/sage-repositories/sage-integration-lmonade/local/include -I/home/tkluck/src/sage-repositories/sage-integration-lmonade/local/include/python2.7 -Igroebner/include testsuite/src/BlockDegLexOrderTest.cc
In file included from /usr/include/boost/type_traits/cv_traits.hpp:21:0,
                 from /usr/include/boost/utility/value_init.hpp:28,
                 from /usr/include/boost/mpl/for_each.hpp:28,
                 from /usr/include/boost/test/unit_test_suite_impl.hpp:29,
                 from /usr/include/boost/test/unit_test_suite.hpp:19,
                 from /usr/include/boost/test/unit_test.hpp:20,
                 from testsuite/src/BlockDegLexOrderTest.cc:17:
/usr/include/boost/type_traits/remove_volatile.hpp:62:32: fout: template argument 1 is invalid
scons: *** [testsuite/src/BlockDegLexOrderTest.o] Error 1
scons: building terminated because of errors.

This target BlockDegLexOrderTest.o does not seem to be built at all in the `sage -i` case, so it doesn't fail either. Is there something in the environment that controls that?

Note that this last command seems to use system-boost instead of local boost, which isn't evident anywhere else in the logfile.

The entire failed log is at: http://paste.ubuntu.com/5581856/
The difference between the two is at http://paste.ubuntu.com/5581857/
(there's some 20 lines of g++ differences where the only difference I can spot is the -pipe flag)

Thanks for your help!
Timo

[Francois Bissey]

Hi Timo,

I know you have heard of lmona.de from Burcin. One of the thing that made lmona.de possible is the work of me and Christopher on the sage-on-gentoo overlay. Basically you are trying to duplicate our work that is already available from layman. I think Alexander Dreyer gave us a patch for the particular problem you have. It is al available in the sage-on-gentoo overlay.

Francois

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

[Timo Kluck]

Op zondag 3 maart 2013 18:35:36 UTC+1 schreef François het volgende:

I know you have heard of lmona.de from Burcin. One of the thing that made lmona.de possible is the work of me and Christopher on the sage-on-gentoo overlay. Basically you are trying to duplicate our work that is already available from layman.

I'm trying not to duplicate too much effort. Actually, I think of what I'm doing as a step-by-step way of eventually replacing the spkg system by either your work or something very close to it, so that it can be maintained together.

Of course, this is not my call to make. For now, it's just investigating the possibilities.

Quoting from a private e-mail (if I may), Burcin wrote:
> IMHO, the problems Sage ran into in the development model cannot be

> solved by maintaining a monolithic library. We need to support
> modularization and customization.

I think that in the long term, he is right about that. However, if it is decided that sage wants to keep distributing source-based releases containing upstream sources as spkg files, it would be a  great thing to at least replace the spkg logic with (something similar to) lmonade. That's what I'm looking into now. I hope that it can share as much code as possible.

The advantage of the library and the package manager sharing a repository would be that you can upgrade the version data in the ebuild and the wrapper code in a single commit. That's useful when things are not as modular as they ideally would be.

 

I think Alexander Dreyer gave us a patch for the particular problem you have. It is al available in the sage-on-gentoo overlay.

Thanks, I'll see if I can find it. 

Best, Timo

[Francois Bissey]

Something I hadn't seen in your original email is that you are trying to build against a private boost rather than the system one. That's definitely lmona.de/prefix territory where you have to make sure your private stuff is looked at first. Not trivial at all.

Francois

--

You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[leif]

Timo Kluck wrote:
> This target BlockDegLexOrderTest.o does not seem to be built at all in
> the `sage -i` case, so it doesn't fail either. Is there something in the
> environment that controls that?

In the "plain" Sage build, you most probably also have

...
Checking for C library boost_unit_test_framework... no
Warning Boost/unit test framework library ( boost_unit_test_framework )
not available. Skipping tests.
...

> Note that this last command seems to use system-boost instead of local
> boost, which isn't evident anywhere else in the logfile.

Note that Sage ships the "boost-cropped" spkg as well, such that
(presumably) other system-wide installations of Boost components do not
"disturb", i.e., don't get picked up by SCons. (More or less just
guessing here.) Still, the build error seems to be a version /
compatibility problem.


-leif

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Timo Kluck]

Op zondag 3 maart 2013 19:32:43 UTC+1 schreef François het volgende:

Something I hadn't seen in your original email is that you are trying to build against a private boost rather than the system one. That's definitely lmona.de/prefix territory where you have to make sure your private stuff is looked at first. Not trivial at all.

That's true. However, I'm still using the spkg-install scripts, which should have got that covered. In fact, from the logs, it is actually using all the right include paths for building polybori. From what I can tell, it's just the testsuite that fails to pick that up. And there is no log for the test suite being built *at all* in the `sage -i` case, so naturally it doesn't fail there.

So unless I'm very much mistaken, I'm only having trouble with whether the tests are built or not. This seems like a small thing to fix --- at least compared to the kind of prefixing problems you refer to.

Maybe I should stress that I'm really trying not to duplicate all that effort that goes into these local builds (which you've already done!). For now, I'm still letting the the sage environment and the spkg-install scripts handle the library finding, and I'm just using emerge for dependency resolution. Then in the long run, I would want to replace my ebuild files by your ebuild files step-by-step.

In fact, everything seems to work except for polybori. If I install only that one manually, the rest seems to work (I still have to run sage -t to make sure).
 

Francois

On 4/03/2013, at 7:12, "Timo Kluck" <tkl...@gmail.com> wrote:

Op zondag 3 maart 2013 18:35:36 UTC+1 schreef François het volgende:

I know you have heard of lmona.de from Burcin. One of the thing that made lmona.de possible is the work of me and Christopher on the sage-on-gentoo overlay. Basically you are trying to duplicate our work that is already available from layman.

I'm trying not to duplicate too much effort. Actually, I think of what I'm doing as a step-by-step way of eventually replacing the spkg system by either your work or something very close to it, so that it can be maintained together.

Of course, this is not my call to make. For now, it's just investigating the possibilities.

Quoting from a private e-mail (if I may), Burcin wrote:
> IMHO, the problems Sage ran into in the development model cannot be

> solved by maintaining a monolithic library. We need to support
> modularization and customization.

I think that in the long term, he is right about that. However, if it is decided that sage wants to keep distributing source-based releases containing upstream sources as spkg files, it would be a  great thing to at least replace the spkg logic with (something similar to) lmonade. That's what I'm looking into now. I hope that it can share as much code as possible.

The advantage of the library and the package manager sharing a repository would be that you can upgrade the version data in the ebuild and the wrapper code in a single commit. That's useful when things are not as modular as they ideally would be.

 

I think Alexander Dreyer gave us a patch for the particular problem you have. It is al available in the sage-on-gentoo overlay.

Thanks, I'll see if I can find it. 

Best, Timo

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To post to this group, send email to sage...@googlegroups.com.

Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Timo Kluck]

Op zondag 3 maart 2013 19:59:25 UTC+1 schreef leif het volgende:

Timo Kluck wrote:
> This target BlockDegLexOrderTest.o does not seem to be built at all in
> the `sage -i` case, so it doesn't fail either. Is there something in the
> environment that controls that?

In the "plain" Sage build, you most probably also have

...
Checking for C library boost_unit_test_framework... no
Warning Boost/unit test framework library ( boost_unit_test_framework )
not available. Skipping tests.
...

This sounds extremely likely to be the problem! The configure log isn't included in the build log, so I didn't notice this. Thanks a lot!
Timo
 

[leif]

FWIW, I've just installed libboost-test[-dev] 1.40.0 (on Ubuntu 10.04.4)
and successfully reinstalled the PolyBoRi spkg, but although I now get

...
Checking for C library boost_unit_test_framework... yes
...

the testsuite doesn't get built (even with SAGE_CHECK=yes).