[cmake-developers] [CMake 0014306]: environment variable set in a add_custom_target is forgotten
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14306
==
Reported By:ycollet
Assigned To:
==
Project:CMake
Issue ID: 14306
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-07-24 03:45 EDT
Last Modified: 2013-07-24 03:45 EDT
==
Summary:environment variable set in a add_custom_target is
forgotten
Description:
Under windows, I set an environment variable and then launch a batch file which
displays the value of the environment variable.
add_custom_target(test_env_var
COMMAND set MYENVVAR=this_is_a_test
COMMAND ${CMAKE_SOURCE_DIR}/echo.bat)
The variable is correctly displayed.
Under linux, I tried to do the same
add_custom_target(test_env_var
COMMAND export MYENVVAR=this_is_a_test
COMMAND ${CMAKE_SOURCE_DIR}/echo.sh)
The shell script displays an empty variable.
To be able to display the environment variable, I must do like this:
add_custom_target(test_env_var
COMMAND export MYENVVAR=this_is_a_test
${CMAKE_SOURCE_DIR}/echo.sh)
And then it works.
Under linux, it's like a new shell is started each time a COMMAND is met.
Under windows, it's like a shell is started at the first COMMAND and the same
shell is reused for each COMMAND.
Steps to Reproduce:
I added an archive with the test case.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-24 03:45 ycolletNew Issue
2013-07-24 03:45 ycolletFile Added: tmp.zip
==
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
On Tue, Jul 23, 2013 at 5:59 PM, Stephen Kelly steve...@gmail.com wrote: Nicolas Desprès wrote: Hi Stephen, Did you have any chance to look at the code? I would love to see it integrated in the next release. That being said, there is no pressure. I'll have a look now. Thanks! +UpdateOutputToSourceMap(outputs, file); is missing a 'this-', as per the style. There's a couple of repeats of that. Done Please rename typedef std::mapstd::string, cmSourceFile* OutputToInputMap; to OutputToSourceMap for similarity to the OutputToSource variable. Done I haven't tried it out yet, but it looks sane to me. The UpdateOutputToSourceMap could probably be faster if outputs is sorted and you use lower-bound insertion in a loop over the map or so. If it's fast enough already though, probably no need for that :). Currently, it is fast enough. The path to optimize was search not the insertion. I have not noticed any performance regression in the insertion. I liked your idea of inserting in at the end of list/vector and then to sort it once the configuration is done but I am afraid this require more knowledge of cmake code base than I have and the patch will be harder to write. That's said we can optimize further as I mentioned in my comment ( https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023). Do you have an opinion about it? I'd say the topic can be cleaned up and force pushed for another review. Done. -Nico -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014307]: add a COMMENT option for execute_process
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14307
==
Reported By:ycollet
Assigned To:
==
Project:CMake
Issue ID: 14307
Category: CMake
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2013-07-24 05:22 EDT
Last Modified: 2013-07-24 05:22 EDT
==
Summary:add a COMMENT option for execute_process
Description:
A COMMENT option for execute_process should be nice.
To do things like:
execute_process(COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_SOURCE_DIR}/test ${CMAKE_BINARY_DIR}/test
COMMENT Copying test into build directory)
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-24 05:22 ycolletNew Issue
==
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote:
+UpdateOutputToSourceMap(outputs, file);
is missing a 'this-', as per the style. There's a couple of repeats of
that.
Done
You seem to have missed this one.
There are also other style issues.
* Don't put an else after a return
* Wrap single line blocks in {}
That's said we can optimize further as I mentioned in my comment (
https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023).
Do you have an opinion about it?
Do I understand correctly that the issue is that OutputToSource values can
be absolute or relative paths? That would be fixable by patching only
UpdateOutputToSourceMap, right?
Thanks,
Steve.
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
On Wed, Jul 24, 2013 at 11:29 AM, Stephen Kelly steve...@gmail.com wrote:
Nicolas Desprès wrote:
+UpdateOutputToSourceMap(outputs, file);
is missing a 'this-', as per the style. There's a couple of repeats of
that.
Done
You seem to have missed this one.
There are also other style issues.
* Don't put an else after a return
* Wrap single line blocks in {}
Done. I hope I did them all.
That's said we can optimize further as I mentioned in my comment (
https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023
).
Do you have an opinion about it?
Do I understand correctly that the issue is that OutputToSource values can
be absolute or relative paths? That would be fixable by patching only
UpdateOutputToSourceMap, right?
Not exactly. According to my tests only
cmMakefiles::GetSourceFileWithOutput's cname argument can be either
relative or absolute. When the mapping table is updated it always get an
absolute path. The previous code of GetSourceFileWithOutput() supported
both relative and absolute paths.
Here my test setup:
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index b68460d..d035e25 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -1029,6 +1029,10 @@ void
cmMakefile::UpdateOutputToSourceMap(const std::string output,
cmSourceFile* source)
{
+ std::cout UPDATE: source-GetFullPath()
+ -
+ output
+ std::endl;
this-OutputToSource[output] = source;
}
@@ -2051,6 +2055,7 @@ cmMakefile::Compare::operator()(const std::string s1,
cmSourceFile *cmMakefile::GetSourceFileWithOutput(const char *cname)
{
std::string name = cname;
+ std::cout QUERY: name std::endl;
OutputToSourceMap::iterator o = this-OutputToSource.find(name);
if (o != this-OutputToSource.end())
{
Now when I run either:
ctest -VV -R ExportImport | tee /tmp/ImportExport-master.log
or
ctest -VV -R '^CustomCommand$' | tee /tmp/CustomCommand-master.log
I get some relative path in the QUERY debug message. That's reason why I
wrote the Compare functor because those tests were failing after my first
patch.
I hope it is clearer now.
Cheers,
-Nico
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote: That's said we can optimize further as I mentioned in my comment ( https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023 ). Do you have an opinion about it? Do I understand correctly that the issue is that OutputToSource values can be absolute or relative paths? That would be fixable by patching only UpdateOutputToSourceMap, right? Not exactly. According to my tests only cmMakefiles::GetSourceFileWithOutput's cname argument can be either relative or absolute. Then patching the callers of GetSourceFileWithOutput is worth looking into. There are not many. You'd have to try it and see if any issues come up. Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014308]: With NMake Makefiles generators under visual studio 2008 nmake test doesn't work
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14308 == Reported By:ycollet Assigned To: == Project:CMake Issue ID: 14308 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-07-24 06:25 EDT Last Modified: 2013-07-24 06:25 EDT == Summary:With NMake Makefiles generators under visual studio 2008 nmake test doesn't work Description: I use Visual Studio 2008 with 64 bits compilation support. Under Linux, I launch my tests via make test. Under Windows, if I launch nmake test, the tests are note started. I've got the following message: e:\ycollet\RiskManager\build_tmp_64nmake test Microsoft (R) Program Maintenance Utility Version 9.00.21022.08 Copyright (C) Microsoft Corporation. Tous droits réservés. 'test' is up to date If I edit Makefile and rename the 'test' rule into 'yc', nmake yc launch the tests. I suspect a problem with nmake. == Issue History Date ModifiedUsername FieldChange == 2013-07-24 06:25 ycolletNew Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Allowed chars in test names
On 07/22/2013 04:18 PM, Rolf Eike Beer wrote: Since d0170584c54b515b7eb2d044c3d48332523b3a37 there is a comment stating that spaces, quotes, or other characters special in CMake syntax are not allowed in a test name. This raised 2 topics: This was just documenting an existing limitation. -first: the only check done in add_test() is that the name is not empty. If there are forbidden characters we must test for them, reject everything that is invalid, and have a check that verifies that this works. One could add such a check and test with a policy for compatibility if the validation is particularly strict. -second: what does special mean? Look at the CMake language lexer. I fear that any test name would end up as some sort of target name in Makefile/project files somewhere They end up in add_test calls in CTestTestfile.cmake files. We might be able to lift some of the limits by re-escaping test names as generated into these files. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] dev/export-target-without-language topic
Ben, Please revise this topic to add a test using the Tests/RunCMake infrastructure to diagnose the error case instead. Thanks, -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] install-interface-includes topic
On 07/15/2013 02:00 PM, Stephen Kelly wrote: Brad King wrote: On 7/15/2013 11:25 AM, Stephen Kelly wrote: The solution I think is to add the specified include directories to the cmTargetExport instance which gets created when using the EXPORT, and to append the directories only when generating. Yes, certainly the INCLUDES DESTINATION needs to be associated with the EXPORT whose targets will get the usage requirement. Ok, I've implemented that. I couldn't squash in the fix commit because that causes a conflict with tid-system-argument, but I guess it can be squashed before merge. Please add an error condition when INCLUDES DESTINATION is used without EXPORT and a test case to cover it. Thanks, -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake -E tar not working correctly with xz-compressed tarballs on MSYS
ping. In sum this cmake -E tar issue for *.tar.xz files needs confirmation for MSYS on the Microsoft version of Windows. I am pretty sure this is a simple issue since under MSYS handling of *.tar.xz files is straightforward from the command line, and my understanding is that libarchive drops back to the command line when necessary. However, to help me generate the appropriate cmake patch I need some further guidance to where in Utilities/cmlibarchive/libarchive I should be looking. Alan On 2013-07-21 13:19-0700 Alan W. Irwin wrote: I created an xz-compressed test tarball on Linux using the J option tar Jcf test.tar.xz ... On Linux, cmake -E tar xfz test.tar.xz unpacks that tarball without issue. For MSYS (on a Wine-1.6-rc4 platform), that same command hangs indefinitely. Wine often does not respond well to ordinary errors so I used ctrl-C to get out of the hang, and the following message was displayed on the command line: unxz: (stdin): File format not recognized To remove the Wine uncertainty could someone attempt a similar MSYS experiment on the Microsoft version of Windows? However, assuming that verification succeeds, then that error message is only delivered if you attempt to do something like (under MSYS) bash.exe-3.1$ cat non-tar.xz_file |unxz -c test_file so I assume that is what cmake is trying to do, and there is some issue accessing the correct file. For example, if I execute (under MSYS) bash.exe-3.1$ cat test.tar.xz |unxz -c test2.tar the resulting tarball, test2.tar is fine. Also, you can create and also unpack xz-compressed tarballs under MSYS using the J option. So on MSYS platforms the command-line tools are working fine for manipulating xz-compressed tarballs, but cmake -E tar xfz test.tar.xz fails (and also appears to be using the unxz command-line tool that is not correctly finding the xz-compressed tarball). I suspect this is a trivial issue since the xz-related command-line tools all work on MSYS, but as always the difficult thing to do with CMake is to find where the issue is occurring. I starting looking in Utilities/cmlibarchive/libarchive, but any additional guidance would be appreciated. Note, the above MSYS tests were done using the Windows binary version of cmake-2.8.11.2 that was obtained by wget http://www.cmake.org/files/v2.8/cmake-2.8.11.2-win32-x86.zip; unzip cmake-2.8.11.2-win32-x86.zip Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Re: cmake -E tar not working correctly with xz-compressed tarballs on MSYS
In sum this cmake -E tar issue for *.tar.xz files needs confirmation for MSYS on the Microsoft version of Windows. I am pretty sure this is a simple issue since under MSYS handling of *.tar.xz files is straightforward from the command line, and my understanding is that libarchive drops back to the command line when necessary. However, to help me generate the appropriate cmake patch I need some further guidance to where in Utilities/cmlibarchive/libarchive I should be looking. libarchive is a “3rd party library” imported into CMake periodically when important updates are made in the upstream library. The difference between the upstream snapshot and what’s in CMake should be minimal. Perhaps you should inquire about this problem on the libarchive mailing list, and see if you can get any guidance there. The fix should be made in upstream libarchive, and then pulled into CMake next time the snapshot is updated. Of course, if you have a trivial one-line fix or something close to it, patching both simultaneously is reasonable. But it should definitely be fixed in upstream libarchive as well if that’s where the problem code is... Sorry I’m not an expert on the libarchive code, and can’t give you a pointer where to look... but I bet somebody on the libarchive list would have a better shot at giving you that pointer. libarchive project page: http://code.google.com/p/libarchive/ Good luck, David C.-- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake -E tar not working correctly with xz-compressed tarballs on MSYS
On 07/21/2013 04:19 PM, Alan W. Irwin wrote: So on MSYS platforms the command-line tools are working fine for manipulating xz-compressed tarballs, but cmake -E tar xfz test.tar.xz fails (and also appears to be using the unxz command-line tool that is not correctly finding the xz-compressed tarball). I suspect this is a trivial issue since the xz-related command-line tools all work on MSYS, but as always the difficult thing to do with CMake is to find where the issue is occurring. I starting looking in Utilities/cmlibarchive/libarchive, but any additional guidance would be appreciated. CMake's build of libarchive does not enable built-in lzma support. Libarchive responds by trying to run a command-line tool to handle the data, probably xz in this case. Something about the MSYS xz trying to run from inside a CMake process environment may cause the problem. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
On Wed, Jul 24, 2013 at 12:18 PM, Stephen Kelly steve...@gmail.com wrote: Nicolas Desprès wrote: That's said we can optimize further as I mentioned in my comment ( https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023 ). Do you have an opinion about it? Do I understand correctly that the issue is that OutputToSource values can be absolute or relative paths? That would be fixable by patching only UpdateOutputToSourceMap, right? Not exactly. According to my tests only cmMakefiles::GetSourceFileWithOutput's cname argument can be either relative or absolute. Then patching the callers of GetSourceFileWithOutput is worth looking into. There are not many. You'd have to try it and see if any issues come up. Ok. I will give it a try tomorrow. I hope it won't bring in part of CMake I do not know. Cheers, -Nico -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake -E tar not working correctly with xz-compressed tarballs on MSYS
On 2013-07-24 16:09- David Cole wrote: In sum this cmake -E tar issue for *.tar.xz files needs confirmation for MSYS on the Microsoft version of Windows. I am pretty sure this is a simple issue since under MSYS handling of *.tar.xz files is straightforward from the command line, and my understanding is that libarchive drops back to the command line when necessary. However, to help me generate the appropriate cmake patch I need some further guidance to where in Utilities/cmlibarchive/libarchive I should be looking. libarchive is a “3rd party library” imported into CMake periodically when important updates are made in the upstream library. The difference between the upstream snapshot and what’s in CMake should be minimal. Perhaps you should inquire about this problem on the libarchive mailing list, and see if you can get any guidance there. The fix should be made in upstream libarchive, and then pulled into CMake next time the snapshot is updated. Of course, if you have a trivial one-line fix or something close to it, patching both simultaneously is reasonable. But it should definitely be fixed in upstream libarchive as well if that’s where the problem code is... Sorry I’m not an expert on the libarchive code, and can’t give you a pointer where to look... but I bet somebody on the libarchive list would have a better shot at giving you that pointer. libarchive project page: http://code.google.com/p/libarchive/ Upstream libarchive is certainly another avenue to explore. For that case probably the best thing to do would be to try and build libarchive on MinGW/MSYS/Wine and test it for *.tar.xz files, and if any part of that does not work, refer the question to the libarchive list. Of course, such an approach may simply demonstrate that recent upstream libarchive is fine (see further comments below). But I will try this approach if I cannot find some other simple fix in CMake for the issue. Meanwhile, can someone with access to MSYS on the Microsoft version of Windows try, for example, the simple experiment of downloading http://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz and unpacking that with cmake -E tar xfz glib-2.32.1.tar.xz to verify (or not) the issue? With regard to the question of the libarchive version that has been imported into CMake, from Utilities/cmlibarchive/README-CMake.txt it appears the last commit that merged upstream libarchive was 4f4fe6e (where details of that commit are given at http://www.cmake.org/pipermail/cmake-commits/2012-January/011742.html). Thus, cmake appears to be using a version of libarchive that is at least one and a half years old. A new import of libarchive may be all that is required to solve this cmake -E tar issue for *.tar.xz files on MSYS (assuming the issue is confirmed as above). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake -E tar not working correctly with xz-compressed tarballs on MSYS
On 2013-07-24 13:18-0400 Brad King wrote: On 07/21/2013 04:19 PM, Alan W. Irwin wrote: So on MSYS platforms the command-line tools are working fine for manipulating xz-compressed tarballs, but cmake -E tar xfz test.tar.xz fails (and also appears to be using the unxz command-line tool that is not correctly finding the xz-compressed tarball). I suspect this is a trivial issue since the xz-related command-line tools all work on MSYS, but as always the difficult thing to do with CMake is to find where the issue is occurring. I starting looking in Utilities/cmlibarchive/libarchive, but any additional guidance would be appreciated. CMake's build of libarchive does not enable built-in lzma support. Libarchive responds by trying to run a command-line tool to handle the data, probably xz in this case. Something about the MSYS xz trying to run from inside a CMake process environment may cause the problem. The first priority is to verify on Microsoft Windows that this is actually an issue using the the simple test I outlined in my previous post. But Wine has been pretty reliable for me so assuming that verification is done, I think you have given a likely explanation of the issue. I would be happy to try and verify that is the issue within CMake but I am having some trouble deciphering what is going on in Utilities/cmlibarchive. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014309]: CHECK_C_COMPILER_FLAG does not behave like the manpage states
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14309 == Reported By:jmcm Assigned To: == Project:CMake Issue ID: 14309 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-07-24 16:20 EDT Last Modified: 2013-07-24 16:20 EDT == Summary:CHECK_C_COMPILER_FLAG does not behave like the manpage states Description: The manpage states that CHECK_C_COMPILER_FLAG accepts the same flags as CHECK_C_SOURCE_COMPILES, but then it overwrites CMAKE_REQUIRED_DEFINITIONS. So either the manpage is wrong or the implementation is wrong. I found the bug because I relied on the documented behaviour - I want to have some fixed flags to be passed to all tests. Workaround (as of now untested): pass the flag to test plus all the fixed flags to CHECK_C_COMPILER_FLAG Steps to Reproduce: Read the source, Luke (Modules/CheckCCompilerFlag.cmake) Additional Information: At least versions 2.8.9 and git HEAD. == Issue History Date ModifiedUsername FieldChange == 2013-07-24 16:20 jmcm New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Allowed chars in test names
Brad King wrote: On 07/22/2013 04:18 PM, Rolf Eike Beer wrote: Since d0170584c54b515b7eb2d044c3d48332523b3a37 there is a comment stating that spaces, quotes, or other characters special in CMake syntax are not allowed in a test name. This raised 2 topics: This was just documenting an existing limitation. Yes, of course. -first: the only check done in add_test() is that the name is not empty. If there are forbidden characters we must test for them, reject everything that is invalid, and have a check that verifies that this works. One could add such a check and test with a policy for compatibility if the validation is particularly strict. -second: what does special mean? Look at the CMake language lexer. So for the beginning I would go and just simply reject every test name that has spaces or quotes, because that has never worked. Eike -- signature.asc Description: This is a digitally signed message part. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
