Noqt #305

Merged
merged 2 commits into from Apr 12, 2013

Projects

None yet

2 participants

@kintel
openscad member

I think I (finally) removed the last Qt dependencies for the core and tests.

Testing/review would be appreciated :)

@donbright
openscad member

this breaks older boost... i think uhm .. fs::canonical was introduced in 1.48 or somewhere around there.

im trying to backport and i got pretty far but there was some bizarre bug that made a handful of import tests fail on an old freebsd machine i was on.

will try again tomorrow (if you havent fixed by then....)

@kintel
openscad member

wops - well, I had a hunch I shouldn't push to master...
It looked so easy - just needed a way of replacing QDir::relativeFilePath().

There is an alternative implementation in boost-utils.cc: boostfs_relative_path().
I somehow trust it less, but haven't really tested it.

@kintel
openscad member

We should document somewhere minimum required versions of libraries, and why we want to be compatible with those versions, so that we can upgrade when the reason to stay compatible goes away.

@kintel
openscad member

hm, but the alternative implementation uses fs::absolute(), which isn't available in older boost versions either..

@kintel
openscad member

It still fails on Boost 1.40 on gcc20: https://rawgithub.com/kintel/5189495/raw/8c6ecf644a960d0af7d802bfc27c09eb41c68d8c/issue-305.html

I'm working on setting up an easier way of testing against different library versions.

@donbright
openscad member

gcc 20 has an outdated version of gmp and it doesn't have glew at all so i have always used the build script on that machine.... i was doing testing on the freebsd 9.0 machine they had... oh well. . . i think it had like boost 1.45..

the few times i did test 'old boost' i edited the version in the build-script file itself and rebuilt the dependencies.... anyways like you said itd be nice to have a policy regarding backports.... the issue with boost is that machines with outdated boost are likely to also have old gmp and/or mpfr, which CGAL uses directly, so it gets complicated....
i am not sure how to approach it really. i have focused energy in the past on making the dependency-build work because so many distros do not have updated CGAL or opencsg or even boost... (and a lot of people dont have root anyways so they cant install things like boost,glew, etc even if they wanted to)

-DB

@kintel
openscad member

On gcc20, I built all libraries using the script, but with old versions, for testing. boost 1.40 was the oldest version I managed to build. The idea was to have an easy way of testing compatibility given the latest boost issues.

I'm hoping to set up a decent collection of builds, and make the deps folders public, so that we all can build against them. Using gcc20 makes my turnaround times vastly faster than building locally on my Mac.

@donbright
openscad member

the problem i have when building older boost is that, older boost has a lot of bugs, for example certain versions of boost are broken against certain versions of gcc and wont build at all, sometimes only portions of boost are broken (like variant.hpp) .... also some older versions of boost have a broken '--prefix' on their install script so the install to home fails, and on and on and on.

@kintel
openscad member

How fun..

Do you remember which version of boost you tested your last changes to this branch on?

@donbright
openscad member

yeah i think it was 1.45 on freebsd 9 (which might work different from linux).

something about dealing with ".." and fs::path.remove_filename() inside of canonical() is what is currently breaking your tests i believe. i have been experimenting with 1.36 but no solid fix yet.

@donbright
openscad member

and by the way you may know this, but the 'openscad example 001' breaks on certain versions of Mesa + Xvfb - including PPC64 Fedora 18, FreebSD 9, and Gcc20 (whatever it is using), but that is a problem in Master not related to boost or 'noqt'.

@donbright donbright backport to boost 1.37. improve dependency build for older lib versions
including the requirement of symlink to $DEPLOYDIR/include/boost if
boost is so old that it uses version numbers in the path name
f242a7a
@donbright
openscad member

ok this is a backport to boost 1.37 tests 100% on gcc 20 (except for example001 which is Xvfb related)

also improved the way boost and CGAL build so that it will be more reliable and not break so often.

it also requires a by-hand symlink of $DEPLOYDIR/include/boost_1_37_0 to $DEPLOYDIR/include/boost

@kintel
openscad member

I believe this should be stable enough to merge into master - any thoughts?

@donbright
openscad member

i say go for it.

@kintel kintel merged commit f242a7a into master Apr 12, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment