[CMake] building static binaries
Hi, I've been trying to implement a feature which would enable building static binaries with cmake, but I've got completely stuck, I hope someone can hint me what's the best way to do this. What I've done is a 2 stage solution for making static binaries: 1) Telling cmake to prefer picking up ".a"-s when searching for libraries (CMAKE_FIND_LIBRARY_SUFFIXES). This works fine, but referring to file extensions/endings might not be general enough. Making it less platform-dependent would require rewriting the way external libraries are treated: instead of adding them with full path we'd need to add -Lpath -llibname separately. Any other ways for doing this? 2) Telling cmake to use static system libraries. This should work with the target property LINK_SEARCH_END_STATIC which essentially should result in a the system libs linked in statically whenever possible (depending on the platform). Well, it seems that even in fairly straightforward situations (Linux + gcc) I get the a linker error: /usr/bin/ld: cannot find -lgcc_s. Obviously, libgcc_s.a is not available, but by looking at the verbose output, the implicit gcc linker call contains the "-Wl,-Bstatic" argument. This AFAIK is not correct, or more precisely not enough to just tell ld to link statically, gcc also has to know about it (through the "-static" argument). Can anyone confirm this? I'd be grateful for tips on how to fix the issue with 2), but I'm open for other portable (and preferably elegant) solutions. Cheers, -- Szilárd ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] rpath business: CPack / running binaries in the build dir
Hi, In order to be able to run binaries linked dynamically to some libraries from the same project the rpath in the build directory has to point to the lib directory in the build directory. However, this brakes CPack which seems to require the CMAKE_BUILD_WITH_INSTALL_RPATH set on to work flawlessly. Is there any way to rewrite rpath while CPack-ing and installing? Note that platform independence is priority #1. Cheers, -- Szilárd ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building static binaries
Hi, First of all, I'd be grateful for a reply to the 2nd of my question. Can anyone confirm that LINK_SEARCH_END_STATIC on Linux + gcc is buggy? @Michael: Thanks for the link, I've actually seen that thread, but I was quite disappointed by the conclusions so I asked with the hope that the opinion of the developers has shifted. I have only one thing to add to the static/shared library finding business. Although I understand that the Win community is large enough to invalidate certain CMake feature requests that do not favor this OS, but IMHO in this case it would be fairly straightforward to implement this feature for at least a dozen *NIX OS-es. In particular, I like the suggestion that Philip Lowman suggested (http://www.mail-archive.com/cmake@cmake.org/msg21354.html). -- Szilárd On Wed, Nov 3, 2010 at 5:57 PM, Michael Hertling wrote: > On 11/02/2010 10:54 PM, Szilárd Páll wrote: >> Hi, >> >> I've been trying to implement a feature which would enable building >> static binaries with cmake, but I've got completely stuck, I hope >> someone can hint me what's the best way to do this. >> >> What I've done is a 2 stage solution for making static binaries: >> >> 1) Telling cmake to prefer picking up ".a"-s when searching for >> libraries (CMAKE_FIND_LIBRARY_SUFFIXES). >> >> This works fine, but referring to file extensions/endings might not be >> general enough. Making it less platform-dependent would require >> rewriting the way external libraries are treated: instead of adding >> them with full path we'd need to add -Lpath -llibname separately. Any >> other ways for doing this? >> >> >> 2) Telling cmake to use static system libraries. >> >> This should work with the target property LINK_SEARCH_END_STATIC which >> essentially should result in a the system libs linked in statically >> whenever possible (depending on the platform). Well, it seems that >> even in fairly straightforward situations (Linux + gcc) I get the a >> linker error: /usr/bin/ld: cannot find -lgcc_s. >> >> Obviously, libgcc_s.a is not available, but by looking at the verbose >> output, the implicit gcc linker call contains the "-Wl,-Bstatic" >> argument. This AFAIK is not correct, or more precisely not enough to >> just tell ld to link statically, gcc also has to know about it >> (through the "-static" argument). Can anyone confirm this? >> >> >> I'd be grateful for tips on how to fix the issue with 2), but I'm open >> for other portable (and preferably elegant) solutions. > > FYI: See [1], and in particular [2] and [3]. > > Regards, > > Michael > > [1] http://www.mail-archive.com/cmake@cmake.org/msg21106.html > [2] http://www.mail-archive.com/cmake@cmake.org/msg21317.html > [3] http://www.mail-archive.com/cmake@cmake.org/msg21416.html > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] changing C/C++ compiler: from CMakeLists/for some sources only, and more
Hi, I need to do some funky things to get my code compiled and I'd like to have some opinion on whether these things are possible or not and what's the best way to do it. 1. Change the C/C++ compiler from CMakeList.txt without triggering the re-generation of the entire cache. I know it sounds strange and not very reasonable, but this would be the best quick/short-term solution for my problem. 2. Is it possible to somehow use multiple C/C++ compilers at the same time in an elegant way? Ideally what I would like to do is to use gcc for most files, but for some swap gcc with another (pretty much compatible) compiler and do something like this: set_source_files_properties(file1 file2 file3 PROPERTIES COMPILER "path_to_new_compiler"). Is it possible to do something like this? (Of course, the "COMPILER" property doesn't exist. :) 3. (How) Can I globally override the CMAKE_SHARED_LIBRARY_[CREATE| LINK|RUNTIME]_C_FLAGS variables without modifying files withing the CMake distribution (e.g. Modules/Platform/Linux.cmake)? 4. Finally, if I want to add support for a new compiler which from CMake's point of view behaves almost like gcc, how do I do that? I fear this is not very easy and I could even live with dirty-ish hacks solved by (some of) 1+3. Tips and tricks are all welcome. Thanks in advance! Cheers, -- Szilárd ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] strange rpath with lotf of ":"-s
Hi, I see strange rpath in binaries inside the build tree, linked in such a way that these can run from the build tree. In some cases the rpath list contains a fairly large amount of ":"-s, sometimes only one at the end. Already one colon is unnecessary (at least in my case), but the case when there are many of them is very strange. After make install-ing the colons are gone, so it's not really a security vulnerability, but it's still strange. Does anyone have any idea whether this is caused by a bug in my CMakeList.txt-s or it's a CMake "feature"? Cheers, -- Szilárd ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] strange rpath with lotf of ":"-s
Thanks Rolf & Michael for the explanation and tips, now it's clear what the colons are for! I will see if CMAKE_NO_BUILTIN_CHRPATH is feasible in our project or not. Regard, -- Szilárd On Thu, Jun 9, 2011 at 11:48 PM, Michael Hertling wrote: > On 06/09/2011 01:08 PM, Rolf Eike Beer wrote: >>> Hi, >>> >>> I see strange rpath in binaries inside the build tree, linked in such >>> a way that these can run from the build tree. In some cases the rpath >>> list contains a fairly large amount of ":"-s, sometimes only one at >>> the end. Already one colon is unnecessary (at least in my case), but >>> the case when there are many of them is very strange. After make >>> install-ing the colons are gone, so it's not really a security >>> vulnerability, but it's still strange. >>> >>> Does anyone have any idea whether this is caused by a bug in my >>> CMakeList.txt-s or it's a CMake "feature"? >> >> If you look closely you will see that both rpaths are of the same length. >> CMake inserts an rpath with lot's of empty settings in the build tree so >> it can simply overwrite this later for the install tree without the need >> to rebuild the file. >> >> Eike > > FYI: This placeholder mechanism is in effect only if an RPATH is > enabled for the installed binaries, e.g. via CMAKE_INSTALL_RPATH, > and it can be switched off by setting CMAKE_NO_BUILTIN_CHRPATH to > TRUE; in the letter case, the final binaries are actually relinked > at installation time instead of being patched with the final RPATH. > See [1] for a related discussion. > > Regards, > > Michael > > [1] http://www.mail-archive.com/cmake@cmake.org/msg35955.html > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ccmake options organization
I would also very much like to see some form of grouping to be possible in ccmake. Right now, the only way to avoid clutter is to mark the large majority of the variables as advanced and keep only the ones that would be used frequently used and this is still just a half-baked solution. One neat way would be to have a tree-like structure (like aptitude) based on variable prefix or even manually listed grouping would be very helpful. -- Szilárd On Mon, Jun 13, 2011 at 4:03 PM, Tim Gallagher wrote: > I agree, I much prefer it too. But the bigger issue for us is that our builds > are on remote machines that we cannot X-forward, so the gui isn't even an > option. > > We've been hearing people in our lab say "It would be nice if..." and so I > thought I'd throw it out there to see what others thought and if our guys are > just lazy/crazy :) > > Tim > > - Original Message - > From: "Michael Wild" > To: cmake@cmake.org > Sent: Monday, June 13, 2011 6:09:07 AM > Subject: Re: [CMake] ccmake options organization > > On 06/13/2011 11:01 AM, Alexander Neundorf wrote: >> On Friday 10 June 2011, Tim Gallagher wrote: >>> Hi all, >>> >>> We have a code that has a lot of options to enable/disable at compile time, >>> and we'd also like to use ccmake to generate input files to run the code >>> (possibly several hundred options combined). But the way the curses gui >>> organizes things makes it really hard/tedious to keep track of things. >>> >>> Has anybody looked into creating something akin to tabs to organize >>> options? A simple way, for example, would be to put options with a common >>> prefix on it's own tab so they stay organized. So anything with CMAKE_ >>> would be on a CMake tab, anything with MPI_ would be on an MPI tab, and so >>> on. >> >> cmake-gui, the really graphical client, does that already in the "Grouped >> View" mode. I'm not sure much work will still go into ccmake. >> >> Alex > > Perhaps other people will tune in, so I just want to say that I much > prefer ccmake over cmake-gui personally. Despite all its quirks which I > would love to see fixed it allows for much faster editing without > forcing me to tediously point and click with the mouse. But then, I'm > also a Vim user... > > Although the grouping would be a nice feature to have in ccmake, it > doesn't bother me since I use the search feature to achieve much the > same. Instead of the grouping, I perhaps would even prefer a filter > feature. Searching and filtering should IMHO support regexes (or globbing). > > Michael > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] add_custom_target dependency list issue
Hi,
I implemented a custom target which depends on several other targets,
including some that I generate beforehand as custom targets and
collect their names in a variable. However, this seems to behave in a
strange way if I list these dependencies like this:
add_custom_target(foo COMMAND [...]
DEPENDS bar ${MORE_DEPENDENCIES}),
where ${MORE_DEPENDENCIES} contains space separated list of e.g "dep1 dep2 dep3"
The error I get with generated makefiles is:
make[3]: *** No rule to make target `path_to_bar/bar dep1 dep2 dep3',
needed by [...] Stop.
The strange thing is that even if I explicitly list the dependency
names instead of passing them through the value of the
MORE_DEPENDECIES variable, I get an error that there is no rule to
make the respective target:
make[3]: *** No rule to make target `dep1', needed by [...] Stop.
What am I doing wrong? The custom targets dep1,2,3 are generated
right before "foo", and all of them seem to work (make dep1,2,3
succeeds).
Regards,
--
Szilárd
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom_target dependency list issue
> The DEPENDS option of ADD_CUSTOM_TARGET() is meant for file-level > dependencies only; use ADD_DEPENDENCIES() for target-level ones. Silly mistake, thanks for pointing it out. However, even if I add target dependencies using ADD_DEPENDENCIES() it seems to take into account only the dependent the binary targets (bar, see above), but the custom ones (dep1,2,3) are completely ignored. What could be still wrong? Also, strangely enough, if I list the binary target in the add_custom_target's DEPENDS section (like in my initial example), it does work. Is this just because I am lucky enough that the the dependency itself is a binary with the same name as the target I actually intended to refer to? -- Szilárd ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom_target dependency list issue
I figured out something that makes me even more puzzled. The following
does _not_ work as expected::
set(DEPS "dep1 dep2 dep3")
add_dependencies(foo bar
${DEPS})
Target "foo" gets only dependent on bar and not dep1,2,3. On the other
hand, manually listing the latter instead of using the DEPS variable
works as well as adding them one-by-one in a loop (where also a
variables is used).
This seems to be _extremely_counterintuitive! Is there some sort of
CMake black-magic or basic rule that I don't know of?
--
Szilárd
On Sun, Sep 26, 2010 at 9:09 PM, Szilárd Páll wrote:
>> The DEPENDS option of ADD_CUSTOM_TARGET() is meant for file-level
>> dependencies only; use ADD_DEPENDENCIES() for target-level ones.
>
> Silly mistake, thanks for pointing it out. However, even if I add
> target dependencies using ADD_DEPENDENCIES() it seems to take into
> account only the dependent the binary targets (bar, see above), but
> the custom ones (dep1,2,3) are completely ignored. What could be still
> wrong?
>
> Also, strangely enough, if I list the binary target in the
> add_custom_target's DEPENDS section (like in my initial example), it
> does work. Is this just because I am lucky enough that the the
> dependency itself is a binary with the same name as the target I
> actually intended to refer to?
>
> --
> Szilárd
>
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom_target dependency list issue
> No black magic, just cmake's rules about variable contents.
> Basically CMake has only 1 type of variable value, thats a string. What
> you created above is a string variable "DEPS" with the value "dep1 dep2
> dep3", i.e. a single string consisting of 3 words separated by spaces.
> Some strings are considered to be a list if you use a cmake command that
> expects a list, these strings need to separate each list entry with a
> semicolon.If you use
Actually I knew about the rules on variable contents as well as the
structure and generation on lists. However I didn't realize that
set(DEPS "dep1 dep2 dep3")
add_dependencies(foo bar
${DEPS})
is not pretty much the same as:
add_dependencies(target-name depend-target1
depend-target2 ...),
which is straight from the documentation.
This is what tricked me and I still think it's counter intuitive, but
after all, it's not the first time cmake makes me sweat with some
trivial stuff :)
I'm realizing that CMake probably generates a list of targets straight
from the command invocation and works on that later on. The/my
confusion roots in the quite weird way that can be used to create
lists (set(var elem1 elem2...)). Correct me if I'm wrong, though!
Thanks a bunch for enlightening me!
Regards,
--
Szilárd
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CHECK_C_COMPILER_FLAG (very) broken with icc!
Hi, I'm using the Intel Compiler v12 and to have a robust build generator, before adding flags to CFLAGS I test them. The following buggy behavior exists in CMake up to v2.8.7: - As Intel issues "icc: command line warning #10006: ignoring unknown option '-asdf'" type warnings which are not handled in CHECK_C_COMPILER_FLAG, checking CFLAGS is completely broken (also reported in bugreport #12576). - However, checking for "-openmp" still returns false! Any idea why does this happen? I can write a custom CHECK_C_COMPILER_FLAG which includes a check for the icc, but I've no clue why the "-openmp" check doesn't work. Additionally, IMHO it's quite unfortunate that such a widely used compiler as the Intel Compiler has such flaky support in CMake. I would rather like to see a more limited feature set, but a well tested and robust one. Cheers, -- Szilárd -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CHECK_C_COMPILER_FLAG (very) broken with icc!
On Fri, Jan 13, 2012 at 6:23 PM, Sean McBride wrote: > On Fri, 13 Jan 2012 17:54:23 +0100, Szilárd Páll said: > >>Additionally, IMHO it's quite unfortunate that such a widely used >>compiler as the Intel Compiler has such flaky support in CMake. > > Searching today's dashboard for "icc", I see only 1 entry: > <http://www.cdash.org/CDash/index.php?project=CMake> > > I'm sure the community would benefit from additional submissions. icc costs > money, making it harder... Sure, I understand that -- although Kitware isn't really a group of free-time OSS coders... Also, I wouldn't have even considered the poor Intel Compiler support unfortunate if I didn't think that CMake tends to compromise when it comes to robustness of implementations. It is no fun to have to test across all *patch versions* of CMake with dozens of configurations :) I could pitch in with running a few Dashboard submissions using Intel Compiler on Linux if that helps, but I doubt I can dedicate a machine for long-term contribution. Cheers, -- Szilárd > -- > > Sean McBride, B. Eng s...@rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montréal, Québec, Canada > > > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] bug in FindOpeMP.cmake ?
Hi, It looks like there is a typo in FindOpenMP.cmake, on Windows the appropriate Intel Compiler flag is "/Qopenmp" not "-Qopenmp" (see http://goo.gl/NPbiJ). Before filing the bug could somebody test/confirm this -- I can't exclude the possibility that the compiler silently accepts "-Qopenmp", but I don't have a system to test it myself. Cheers, -- Szilárd -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] bug in FindOpeMP.cmake ?
Additionally, the FindOpenMP.cmake implementation could see some improvements: - It prints excessive amount of messages to the standard output, 30x2 lines before it fails, which is quite annoying and the module doesn't fully respect the QUIET parameter. - The error message can be confusing for users as it is refers to not being able to find OpenMP, while in fact the issue is that the respective compiler does not support it. I'll go ahead and file a bug report for the previously mentioned flag bug. Should I file the above request for improvement separately? Cheers, -- Szilárd On Sat, Jan 14, 2012 at 6:18 PM, Szilárd Páll wrote: > Hi, > > It looks like there is a typo in FindOpenMP.cmake, on Windows the > appropriate Intel Compiler flag is "/Qopenmp" not "-Qopenmp" (see > http://goo.gl/NPbiJ). > > Before filing the bug could somebody test/confirm this -- I can't > exclude the possibility that the compiler silently accepts "-Qopenmp", > but I don't have a system to test it myself. > > Cheers, > -- > Szilárd -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] boostrap error - borked cmConfigure.h [v2.8.12.1]
Hi, I'm trying to compile 2.8.12.1, but I keep bumping into an error: [...] /tmp/cmake-2.8.12.1/Bootstrap.cmk/cmConfigure.h:27:24: warning: missing terminating " character [enabled by default] "8define CMAKE_DATA_DIR "/share/cmake-2 [...] This seems to be caused by a rather messed up-looking cmConfigure.h: [...] /* #undef CMAKE_NO_ANSI_STRING_STREAM */ /* #undef CMAKE_NO_ANSI_FOR_SCOPE */ #define CMAKE_ROOT_DIR "/home/pszilard/tmp/cmake-2.8.12.1" #define CMAKE_DATA_DIR "/share/cmake-2^M.8^M" #define CMAKE_BOOTSTRAP Note that I've manually added the "^M" control characters which would show up as newlines when pasted into the mail client. I've tried running on both an Ubuntu 10.04 and 12.04 machine with different compiler versions, but of course, no compiler swallowed this broken include file. Any ideas what's going on? Cheers, -- Szilárd -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] boostrap error - borked cmConfigure.h [v2.8.12.1]
Found a workaround: $ find /tmp/cmake-2.8.12.1 -type f | xargs dos2unix This must be a bug, should I file a report? -- Szilárd On Fri, Jan 10, 2014 at 1:21 PM, Szilárd Páll wrote: > Hi, > > I'm trying to compile 2.8.12.1, but I keep bumping into an error: > [...] > /tmp/cmake-2.8.12.1/Bootstrap.cmk/cmConfigure.h:27:24: warning: > missing terminating " character [enabled by default] > "8define CMAKE_DATA_DIR "/share/cmake-2 > [...] > > This seems to be caused by a rather messed up-looking cmConfigure.h: > [...] > /* #undef CMAKE_NO_ANSI_STRING_STREAM */ > /* #undef CMAKE_NO_ANSI_FOR_SCOPE */ > #define CMAKE_ROOT_DIR "/home/pszilard/tmp/cmake-2.8.12.1" > #define CMAKE_DATA_DIR "/share/cmake-2^M.8^M" > #define CMAKE_BOOTSTRAP > > Note that I've manually added the "^M" control characters which would > show up as newlines when pasted into the mail client. > > I've tried running on both an Ubuntu 10.04 and 12.04 machine with > different compiler versions, but of course, no compiler swallowed this > broken include file. > > Any ideas what's going on? > > Cheers, > -- > Szilárd -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] boostrap error - borked cmConfigure.h [v2.8.12.1]
Indeed, I did (accidentally) download the .zip package. I was rather annoyed that the bootstrap script did not have executable permission set, but it did not ring a bell... Thanks guys! Just for curiosity: - what *nix tool does not support CR+LF? - the cross-platform codes I work on use LF newlines but build without problem on Windows (msvc, intel, gcc). Why does CMake need two separate packages with different newlines? Cheers, -- Szilárd On Fri, Jan 10, 2014 at 2:56 PM, Andreas Pakulat wrote: > Hi, > > On Fri, Jan 10, 2014 at 2:16 PM, Szilárd Páll wrote: >> >> Found a workaround: >> $ find /tmp/cmake-2.8.12.1 -type f | xargs dos2unix >> >> This must be a bug, should I file a report? > > > Did you use the .zip file of the CMake sources? That one is intended to be > used for Windows and hence contains Windows lineendings. Thus its not > surprising that you have to convert that to unix first, not all *nix tools > can handle windows lineendings. > > Alternatively you can use the *.tar.* download of the CMake sources. > > Andreas > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] passing a URL to cmake on the command line
Hi, I'm trying to pass a URL (that's used in ExternalProject_Add), and I'm having trouble convincing bash + cmake to cooperate. No matter what I've done, one fo the "/" gets dropped from "http://";. Any ideas how can I construct an invocation similar to the one below that will actually work? cmake . -DMY_CUSTOM_URL='http://my-server.com/foobar.tar.gz' Thanks, -- Szilárd -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] passing a URL to cmake on the command line
Hi, My bad, looks like we had an offending line in our CMake scripts, something like set(MY_URL "http://default-url.com/foobar.tar.gz"; CACHE PATH "URL from where to download") The PATH type seems to have caused the issue rather than the mechanism of passing the URL to on the bash command line to cmake. Thanks for the quick feedback! Cheers, -- Szilárd On Mon, Apr 9, 2018 at 5:44 PM, Haocheng Liu wrote: > Hi Szilard, > > I tried it in CMake 3.10 and it works fine(No slash is dropped). Which > version of CMake are you using? > > On Mon, Apr 9, 2018 at 11:24 AM, Szilárd Páll wrote: >> >> Hi, >> >> I'm trying to pass a URL (that's used in ExternalProject_Add), and I'm >> having trouble convincing bash + cmake to cooperate. No matter what >> I've done, one fo the "/" gets dropped from "http://";. >> >> Any ideas how can I construct an invocation similar to the one below >> that will actually work? >> >> cmake . -DMY_CUSTOM_URL='http://my-server.com/foobar.tar.gz' >> >> >> Thanks, >> -- >> Szilárd >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake > > > > > -- > Best regards > Haocheng > > Haocheng LIU > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4421 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
