Re: [cmake-developers] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 2012-10-25 23:42-0400 Bill Hoffman wrote: Either one [of the executables] should show the issue. I did show the wrong output. When it fails you get no output. I now have a much simplified file (compressed so that mailers won't mess it up, but uncompressed it expands only to 205 bytes) to search that still triggers the issue (no output from downloaded cmake while the bootstrapped version finds the string). I used emacs to cut out everything after INFO:compiler[GNU]INFO:platform[] in the file and a lot before it including many long chains of NULLS that were between non-NULL characters. The pattern of the non-NULL characters before the string appears to be important for triggering the bug. If I cut out any of them, suddenly the downloaded CMake starts working and finds INFO:compiler[GNU]INFO:platform[]. So from these experiments it appears a particular pattern of certain strings delimited by NULLs where the number of NULLs don't matter (although I didn't check by removing all NULLs whether at least one NULL is necessary between these particular strings) is required to trigger the issue. All other patterns I have tried of similar or smaller size prior to the string being searched for do not trigger the bug. Thus, I am beginning to wonder if there is some hash collision going on under Wine (only for instructions issued by the compiler used for the downloaded version) that is causing this particular short pattern of non-NULL characters delimited by NULL ones to cause a failure in the search for the string? Anyhow, I urge those who have installed Wine to play with this some more by editing the attached file with emacs to see what byte pattern triggers the bug (no output) and what patterns do not trigger the bug (output of -- [INFO:compiler[GNU]INFO:platform[]] ) for the downloaded version of CMake. 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 __ INFO_string.dat.gz Description: compressed version of short file to be searched that still triggers the bug -- 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] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 2012-10-25 23:26-0600 Clinton Stimpson wrote: Alan, you are in luck. They fixed it two days ago!! At first, I was confused because I was not able to reproduce it, then trying it against an older version of Wine showed the problem. commit 4a566ed3d6acd8a6e18eeaeb41d55d0f793029de Author: Piotr Caban pi...@codeweavers.com Date: Tue Oct 23 18:11:06 2012 +0200 msvcp90: Convert characters to unsigned char before passing them to functions operating on integers. That's awesome. More off list about how I can get access to this patch myself for 1.3.15 so I can do some further comprehensive testing with the downloaded CMake version. 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] Generator expressisons in target properties (was Re: conditionals in generator expressions)
Stephen Kelly wrote: The topics use-generator-target and target-location-configure-time don't depend on anything or each other, so I can work on merging them when development opens again. After that export-at-generate-time can be rewritten. After that I'll get the contents of use-generator-target-2 in, probably split into multiple topics so that the nightlies feedback stays managable. Then we can return to the link depends issues, followed by everything else. I thought about this a little bit and looked into the code, and I'm not sure it's a good plan. Making export() at generate time work means that the whole functionality needs to be available through cmTarget, and that means that almost all of the use-generator-target-2 branch would need to be copying instead of moving. To reduce code duplication it might be possible to use templates, but because the API would need to remain on cmTarget, there wouldn't be any compile-time guard by having the API also on cmGeneratorTarget. It might be possible to make some of the API in cmTarget private, but that would require template-friends, and I doubt the dashboard is ok with that. It also wouldn't solve the whole problem anyway as it's still accessible from cmTarget (this means that it's easier to add features similar to the LOCATION property). So, the requirement to access linking-related information makes it not worth moving to cmGeneratorTarget. So, I'm now thinking that a better solution would be to port the cmGeneratorExpression API back to cmTarget, and have run-time determination of whether to strip or process the link-related properties. The new plan would be: * Port cmGeneratorExpression API to cmTarget * Add a way to determine at runtime whether linking-related information is being requested at configure-time or generate-time. A property on the Makefile might work. * Add a const char *config where appropriate to cmTarget API to pass to the generator expressions. * Return to the depends issue and everything else. Any thoughts on that? Have I missed something? 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] Generator expressisons in target properties
On 10/26/2012 06:10 AM, Stephen Kelly wrote: The new plan would be: * Port cmGeneratorExpression API to cmTarget * Add a way to determine at runtime whether linking-related information is being requested at configure-time or generate-time. A property on the Makefile might work. * Add a const char *config where appropriate to cmTarget API to pass to the generator expressions. * Return to the depends issue and everything else. Sounds good. Due to things like the LOCATION properties and export() we have long supported on-demand evaluation of things at configure time that normally should not be needed until generate time. Hence the undefined behavior of setting certain properties too late. Essentially someone needs to be able to ask at configure time What would this be if we generate now?. If we had CMake to do over again we would not allow this but it is long since too late for that. -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] [CMake 0013609]: RPM generator wrongly add parents directories to the package
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13609 == Reported By:barth Assigned To: == Project:CMake Issue ID: 13609 Category: CPack Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-10-26 14:55 CEST Last Modified: 2012-10-26 14:55 CEST == Summary:RPM generator wrongly add parents directories to the package Description: When an install instruction is added such as : install(FILES xxx.conf DESTINATION /etc/httpd/conf.d) then the section %files in the generated spec file contains : %dir /etc %dir /etc/httpd %dir /etc/httpd/conf.d It is wrong as the RPM must not own system directories. == Issue History Date ModifiedUsername FieldChange == 2012-10-26 14:55 barth 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] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 2012-10-26 02:15-0700 Alan W. Irwin wrote: On 2012-10-25 23:26-0600 Clinton Stimpson wrote: Alan, you are in luck. They fixed it two days ago!! At first, I was confused because I was not able to reproduce it, then trying it against an older version of Wine showed the problem. commit 4a566ed3d6acd8a6e18eeaeb41d55d0f793029de Author: Piotr Caban pi...@codeweavers.com Date: Tue Oct 23 18:11:06 2012 +0200 msvcp90: Convert characters to unsigned char before passing them to functions operating on integers. That's awesome. Furthermore, I just discovered that patch got into the just-released Wine-1.5.16 so I will give that version a try for my comprehensive checks rather than attempting to carry on with a patched version of 1.5.15. 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
