Trick to getting "cd tests; cmake .; make" to run with new files with coal dependencies?
Hey Everyone,
Subject asks it all.
Working on this: https://github.com/clothbot/openscad/tree/read_issue1324 https://github.com/clothbot/openscad/tree/read_issue1324
…I can’t seem to get the existing ./tests to run, let alone add new ones for my experimental CGAL “pointset()” and “skin_surface()” primitives and “read_xyz()” function support. I start getting errors like the following at make-time:
—snip—
In file included from /Volumes/CaseSensitive/ClothBotDesigns/Projects/clothbot/github/clothbot/openscad/openscad/src/primitives-cgal.cc:27:
In file included from /Volumes/CaseSensitive/ClothBotDesigns/Projects/clothbot/github/clothbot/openscad/openscad/tests/../src/module.h:3:
In file included from /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/string:439:
In file included from /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/algorithm:627:
In file included from /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/utility:157:
/opt/local/libexec/llvm-3.7/bin/../include/c++/v1/__tuple:266:60: error: no member named 'value' in 'std::__1::is_convertible<const CGAL::Point_3CGAL::Epick &, CGAL::Point_3CGAL::Epick >'
is_convertible<_Tp0, _Up0>::value &&
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
/opt/local/libexec/llvm-3.7/bin/../include/c++/v1/__tuple:278:12: note: in instantiation of template class 'std::__1::__tuple_convertible_imp<std::__1::__tuple_types<const CGAL::Point_3CGAL::Epick &, const CGAL::Vector_3CGAL::Epick &>, std::__1::__tuple_types<CGAL::Point_3CGAL::Epick, CGAL::Vector_3CGAL::Epick > >' requested here
: public __tuple_convertible_imp<
^
/opt/local/libexec/llvm-3.7/bin/../include/c++/v1/__tuple:291:14: note: in instantiation of template class 'std::__1::__tuple_convertible_apply<true, const std::__1::pair<CGAL::Point_3CGAL::Epick, CGAL::Vector_3CGAL::Epick > &, std::__1::pair<CGAL::Point_3CGAL::Epick, CGAL::Vector_3CGAL::Epick > >' requested here
: public __tuple_convertible_apply<tuple_size<typename remove_reference<_Tp>::type>::value ==
—end-snip—
Thoughts? Suggestions?
Andrew.
--
"The future is already here. It's just not very evenly distributed" -- William Gibson
Darn autocorrect! CGAL dependencies, not “coal” dependencies.
On Jan 24, 2016, at 8:03 PM, Andrew Plumb andrew@plumb.org wrote:
Hey Everyone,
Subject asks it all.
Working on this: https://github.com/clothbot/openscad/tree/read_issue1324 https://github.com/clothbot/openscad/tree/read_issue1324
…I can’t seem to get the existing ./tests to run, let alone add new ones for my experimental CGAL “pointset()” and “skin_surface()” primitives and “read_xyz()” function support. I start getting errors like the following at make-time:
—snip—
In file included from /Volumes/CaseSensitive/ClothBotDesigns/Projects/clothbot/github/clothbot/openscad/openscad/src/primitives-cgal.cc http://primitives-cgal.cc/:27:
In file included from /Volumes/CaseSensitive/ClothBotDesigns/Projects/clothbot/github/clothbot/openscad/openscad/tests/../src/module.h:3:
In file included from /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/string:439:
In file included from /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/algorithm:627:
In file included from /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/utility:157:
/opt/local/libexec/llvm-3.7/bin/../include/c++/v1/__tuple:266:60: error: no member named 'value' in 'std::__1::is_convertible<const CGAL::Point_3CGAL::Epick &, CGAL::Point_3CGAL::Epick >'
is_convertible<_Tp0, _Up0>::value &&
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
/opt/local/libexec/llvm-3.7/bin/../include/c++/v1/__tuple:278:12: note: in instantiation of template class 'std::__1::__tuple_convertible_imp<std::__1::__tuple_types<const CGAL::Point_3CGAL::Epick &, const CGAL::Vector_3CGAL::Epick &>, std::__1::__tuple_types<CGAL::Point_3CGAL::Epick, CGAL::Vector_3CGAL::Epick > >' requested here
: public __tuple_convertible_imp<
^
/opt/local/libexec/llvm-3.7/bin/../include/c++/v1/__tuple:291:14: note: in instantiation of template class 'std::__1::__tuple_convertible_apply<true, const std::__1::pair<CGAL::Point_3CGAL::Epick, CGAL::Vector_3CGAL::Epick > &, std::__1::pair<CGAL::Point_3CGAL::Epick, CGAL::Vector_3CGAL::Epick > >' requested here
: public __tuple_convertible_apply<tuple_size<typename remove_reference<_Tp>::type>::value ==
—end-snip—
Thoughts? Suggestions?
Andrew.
--
"The future is already here. It's just not very evenly distributed" -- William Gibson
Me: http://clothbot.com/wiki/ http://clothbot.com/wiki/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
"The future is already here. It's just not very evenly distributed" -- William Gibson
On Jan 24, 2016, at 20:03 PM, Andrew Plumb andrew@plumb.org wrote:
…I can’t seem to get the existing ./tests to run, let alone add new ones for my experimental CGAL “pointset()” and “skin_surface()” primitives and “read_xyz()” function support. I start getting errors like the following at make-time:
Some ideas/questions:
o you say you didn’t get existing tests to run, but your errors are using your own branch
o Why are you using clang from /opt/local/libexec? Which compiler is this?
o Note: You don’t need to run ‘make’ in tests to run the majority of the tests (you only need the main OpenSCAD binary compiled with the normal build system).
o How did you install the dependencies?
-Marius
On Jan 24, 2016, at 9:06 PM, Marius Kintel marius@kintel.net wrote:
On Jan 24, 2016, at 20:03 PM, Andrew Plumb andrew@plumb.org wrote:
…I can’t seem to get the existing ./tests to run, let alone add new ones for my experimental CGAL “pointset()” and “skin_surface()” primitives and “read_xyz()” function support. I start getting errors like the following at make-time:
Some ideas/questions:
o you say you didn’t get existing tests to run, but your errors are using your own branch
o Why are you using clang from /opt/local/libexec? Which compiler is this?
o Note: You don’t need to run ‘make’ in tests to run the majority of the tests (you only need the main OpenSCAD binary compiled with the normal build system).
o How did you install the dependencies?
-Marius
Ah good, that gives me some things to try.
-
I installed dependencies via the ‘source setenv_mac-qt5.csh; ./scripts/macosx-build-dependencies’ and didn’t have any trouble building and running OpenSCAD.app
-
To clarify, yes I was able to build OpenSCAD.app and ‘cd tests;cmake .;make’ from the master branch, i.e. without my mods.
-
After switching git branches back to my mods, the errors (re)appeared; they are specific to my additions, but limited in scope to the ./tests. OpenSCAD.app itself was building+running fine via qmake;make.
-
I had been using ‘mp-gcc5’ via macports for something else a while back. Forgot about that; I’ve done a ’sudo port select gcc none’ to try with Xcode(7) /usr/bin/gcc defaults next.
On a related note, when I first tried building the tests, it wouldn’t work because I only had Xcode 7 installed, which only has MacOSX10.11.sdk; ./tests cmake was looking for MacOSX10.10.sdk. I downloaded and installed latest/last Xcode6 and added links to the MacOSX10.10.sdk and MacOSX10.9.sdk to satisfy those dependencies:
cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
ln -s /Applications/Xcode6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
ln -s /Applications/Xcode6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
I’ve started building ../libraries again from scratch, using Xcode7 default /usr/bin/gcc. For reference:
—snip—
ClothBotDesigns:openscad clothbot$ which gcc
/usr/bin/gcc
ClothBotDesigns:openscad clothbot$ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin15.3.0
Thread model: posix
ClothBotDesigns:openscad clothbot$ which cmake
/opt/local/bin/cmake
ClothBotDesigns:openscad clothbot$ cmake -version
cmake version 3.4.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
—end-snip—
I know cmake is a fickle beast though, so it won’t surprise me if/when I have to do ‘something special’ to get it running.
Andrew.
--
"The future is already here. It's just not very evenly distributed" -- William Gibson
On Jan 24, 2016, at 23:03 PM, Andrew Plumb andrew@plumb.org wrote:
- After switching git branches back to my mods, the errors (re)appeared; they are specific to my additions, but limited in scope to the ./tests. OpenSCAD.app itself was building+running fine via qmake;make.
This sounds a bit like you’re building the tests with a different compiler or c++ lib than the main binary.
Perhaps you had an old compiled version there which cmake cached?
‘rm CMakeCache.txt' + rebuild usually fixes that
On a related note, when I first tried building the tests, it wouldn’t work because I only had Xcode 7 installed, which only has MacOSX10.11.sdk; ./tests cmake was looking for MacOSX10.10.sdk.
The cmake build looks for the SDK for which it was configured. Another indicator of the above suspicion.
I’ve started building ../libraries again from scratch, using Xcode7 default /usr/bin/gcc. For reference:
Note: Xcode doesn’t use gcc by default, but clang. The gcc shipping with Xcode is ancient and I wouldn’t use it for anything.
C++ is a bit tricky, especially on Mac, since there are two C++ libraries which are not binary compatible with each other. Care must be taken that all C++ dependencies are build using the same library (see -stdlib=libstdc++ vs. -stdlib=libc++). We have some code in our build systems for choosing the correct one (by inspecting the boost library).
If you in addition installed additional compilers, that problem might compound : /
-Marius
Hi Marius,
Quick sanity check on the travis-ci side of things:
https://s3.amazonaws.com/archive.travis-ci.org/jobs/105173124/log.txt
--snip--
src/version_check.h:65:2: warning: #warning CGAL library version is old,
risking buggy behavior. Please see README.md. Continuing anyway. [-Wcpp]
--end-snip--
Is that expected? Is travis-ci currently set up to use an older version of
CGAL than the cgal 4.6.3 default in
https://github.com/openscad/openscad/blob/master/scripts/macosx-build-dependencies.sh
If so, that could explain why it's trying to use taucs.h and not respecting
the '#define CGAL_EIGEN3_ENABLED' line I have in cgalutils.h
--snip--
/usr/include/CGAL/Taucs_fix.h:46:23: fatal error: taucs.h: No such file or
directory
--end-snip--
See https://github.com/clothbot/openscad/blob/read_issue1324/src/cgalutils.h
On the original matter w.r.t not being able to run tests, I haven't figured
it out yet, but I did go through the motions of completely uninstalling
macports, then selectively adding 'ports' back until I could
'scripts/macosx-build-dependencies.sh; qmake openscad.pro; make' cleanly
again. I don't have any macports compiler variants installed anymore to
confuse the issue.
This evening I'll try stepping through the cmake-generated
Makefiles+deps+settings and compare/contrast with qmake-generated Makefile.
Andrew.
--
View this message in context: http://forum.openscad.org/Trick-to-getting-cd-tests-cmake-make-to-run-with-new-files-with-coal-dependencies-tp15877p15926.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Von: clothbot andrew@plumb.org
--snip--
src/version_check.h:65:2: warning: #warning CGAL library version is old,
risking buggy behavior. Please see README.md. Continuing anyway. [-Wcpp]
--end-snip--
Is that expected? Is travis-ci currently set up to use an older version of
CGAL than the cgal 4.6.3 default in
Expected yes, wanted no.
Travis-CI still runs on Ubuntu 12.04 which is creating all sorts of issues
and https://github.com/travis-ci/travis-ci/issues/2046 (migration to 14.04)
is still open while 16.04LTS is almost there. Well it's a free service and
hugely useful, still it would make our life much easier if they'd go to
at least 14.04 as this provides a reasonable list of dependencies without
adding external stuff.
I guess one option would be to see if we can get a newer CGAL compiled
for Ubuntu 12.04 and integrate that in the meantime.
ciao,
Torsten.
tp3 wrote
Von: clothbot <
andrew@
>
--snip--
src/version_check.h:65:2: warning: #warning CGAL library version is old,
risking buggy behavior. Please see README.md. Continuing anyway. [-Wcpp]
--end-snip--
Is that expected? Is travis-ci currently set up to use an older version
of
CGAL than the cgal 4.6.3 default in
Expected yes, wanted no.
Travis-CI still runs on Ubuntu 12.04 which is creating all sorts of issues
and https://github.com/travis-ci/travis-ci/issues/2046 (migration to
14.04)
is still open while 16.04LTS is almost there. Well it's a free service and
hugely useful, still it would make our life much easier if they'd go to
at least 14.04 as this provides a reasonable list of dependencies without
adding external stuff.
I guess one option would be to see if we can get a newer CGAL compiled
for Ubuntu 12.04 and integrate that in the meantime.
ciao,
Torsten.
Looks like Ubuntu 12.04 is equivalent to Debian Wheezy aka Debian 7:
http://www.cgal.org/FAQ.html#debian_packages
http://askubuntu.com/questions/445487/which-ubuntu-version-is-equivalent-to-debian-squeeze/445496
https://www.debian.org/releases/
...and I see cgal 4.6.1 / deb7 packages listed here:
http://debian.cgal.org/archive/
...so it looks theoretically possible to at least get to 4.6.1. As always,
devil's in the details.
Andrew.
--
View this message in context: http://forum.openscad.org/Trick-to-getting-cd-tests-cmake-make-to-run-with-new-files-with-coal-dependencies-tp15877p15929.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Jan 27, 2016, at 09:51 AM, clothbot andrew@plumb.org wrote:
On the original matter w.r.t not being able to run tests, I haven't figured
it out yet, but I did go through the motions of completely uninstalling
macports, then selectively adding 'ports' back until I could
'scripts/macosx-build-dependencies.sh; qmake openscad.pro; make' cleanly
again. I don't have any macports compiler variants installed anymore to
confuse the issue.
This evening I'll try stepping through the cmake-generated
Makefiles+deps+settings and compare/contrast with qmake-generated Makefile.
Also keep in mind that both qmake and cmake caches some configuration info. That may mess something up.
..and if you’re on Mac, remember to 'source setenv_mac-qt5.sh' to point the build system to yourself-built dependencies.
If you do this, external software shouldn’t influence your build, but there might be bugs. It’s just hard to reproduce without access to the computer in question..
-Marius
kintel wrote
On Jan 27, 2016, at 09:51 AM, clothbot <
andrew@
> wrote:
On the original matter w.r.t not being able to run tests, I haven't
figured
it out yet, but I did go through the motions of completely uninstalling
macports, then selectively adding 'ports' back until I could
'scripts/macosx-build-dependencies.sh; qmake openscad.pro; make' cleanly
again. I don't have any macports compiler variants installed anymore to
confuse the issue.
This evening I'll try stepping through the cmake-generated
Makefiles+deps+settings and compare/contrast with qmake-generated
Makefile.
Also keep in mind that both qmake and cmake caches some configuration
info. That may mess something up.
..and if you’re on Mac, remember to 'source setenv_mac-qt5.sh' to point
the build system to yourself-built dependencies.
If you do this, external software shouldn’t influence your build, but
there might be bugs. It’s just hard to reproduce without access to the
computer in question..
-Marius
Yeah, agreed on the limitations without console access. I'm sharing the
update more for the searchable archive than anything else, in case someone
runs into the same/similar issues in future. :-)
I have things sufficiently parred down that the initial 'qmake;make' won't
succeed without explicitly sourcing setenv_mac-qt5.sh, and am in the habit
of shutting down my Terminal.app periodically to flush out any memory it may
have accumulated.
...It could be something as simple as needing to tweak
https://github.com/clothbot/openscad/blob/read_issue1324/tests/cgalcachetest.cc
with some extra header additions to properly resolve the new CGAL features
I'm using. To be determined...
Andrew.
--
View this message in context: http://forum.openscad.org/Trick-to-getting-cd-tests-cmake-make-to-run-with-new-files-with-coal-dependencies-tp15877p15936.html
Sent from the OpenSCAD mailing list archive at Nabble.com.