Menu
▾
▴
#64 cmake does not allow "=" in SRCDIR which 0compiles uses
I just tried to create a 0compile xml for a program that makes use of cmake.
I try to run the following commands to compile the source:
cd "$SRCDIR" && cmake . && make && make install
Problem is, that SRCDIR contains a "=" in it path:
SRCDIR=/home/foo/.cache/0install.net/implementations/sha1new=0bb6a5eee09ba46816300e3539791fe2efa75c88
which is unsupported by cmake:
The path to the source directory:
/home/foo/.cache/0install.net/implementations/sha1new=0bb6a5eee09ba46816300e3539791fe2efa75c88
contains unsupported character '='.
Please use a different source directory name.
Is there a workaround available?
I think this was fixed recently:
http://www.cmake.org/Bug/view.php?id=12934
Seems you are right.
Question is at what time the patch will hit a release.
Also, the author says that cmake only warns about it, and that the limitation comes from make.
Does 0install really depend on this "=" sign?
Many Linux distros will ship a too old cmake version for the next several months/years which prevents all the users to compile programs which depend on cmake.
And even if cmake gets updated, it's not unlikely that make will continue to trouble.
It shouldn't matter if distributions supply an old version of cmake; you can always depend on the version you need using 0install ;-)
http://afb.users.sourceforge.net/zero-install/interfaces/cmake.xml
There's a test example here:
http://afb.users.sourceforge.net/zero-install/interfaces/testbin-cmake.xml
Anders, is the "=" issue fixed now? And should we move the cmake feed to a more permanent location (e.g. repo)?
I do believe it was fixed recently, and that it will be available in a future release of cmake. Yes, we should move the feed but I don't think it helps in this case unless we apply the patch and rebuild all binaries ?
I'm thinking that we might need an option in 0compile, to symlink-or-copy the $SRCDIR to a temporary location and use that instead of the store directly. The overhead, at least on Linux/Unix, should be tiny. And it would be better than having to use "dup-src", which always copies and requires making an in-source build.
@cmake from 0install: good point :)
I like the idea with the symlinks as a workaround if not only cmake but make as well should trouble.
gcc already has the same problem, which was worked around with a symlink:
http://afb.users.sourceforge.net/zero-install/interfaces/libstdc++5.xml
I solved the problem with a symlink as well.
So if you want to, close this report.
OK. Sounds like we have a work-around that can be used until the next cmake release. Thanks,
Symlinks are not portable, so goes against using CMake in the first place. The current workaround is to use "dup-src" and "cmake .", to copy everything and make an in-source build. But that's a bit wasteful, and not recommended either. So an alternative would be to introduce a new attribute, "tmp-src" (or something), that would symlink on Unix and copy on Windows. And then the $SRCDIR would also be in tmp (without the '=').
Would that be more or less work than making a binary release of the current cmake dev version?
Probably more, but might be useful for the cases where '=' actually is a problem (with make) even when it is OK with the cmake Makefile generator. Of course, it does require a new version of 0compile to work.
I suppose that you need the "=" in the path as a delimiter, is that correct?
If so, how much work would it be to use three underscores instead?