I think I (finally) removed the last Qt dependencies for the core and tests.
Testing/review would be appreciated :)
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....)
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.
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.
hm, but the alternative implementation uses fs::absolute(), which isn't available in older boost versions either..
Merge pull request #313 from openscad/noqt_tweaks
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.
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)
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.
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.
Do you remember which version of boost you tested your last changes to this branch on?
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.
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'.
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
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
I believe this should be stable enough to merge into master - any thoughts?
i say go for it.