Re: [cmake-developers] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
Here is the current status of the hunt for the solution of this issue. In sum, the subject line should be changed to Incomplete gfortran library link command always issued for downloaded Microsoft version of CMake but not for a bootstrapped version of CMake for MinGW/MSYS on Wine-1.5.15 My original concerns about CMake generating bad Fortran link commands on a Windows platform involved results from two closely related software projects, ephcom and te_gen. An older version of ephcom tested well on Linux and CMake/MinGW/MSYS/Wine last year, and the latest version tests well on Linux currently. te_gen is recently resurrected (last released in 1999) Fortran software that strongly depends on ephcom and which tests well on Linux currently, but which had never been tested on Windows (CMake/MinGW/MSYS/Wine) before. Both te_gen and ephcom demonstrated that the downloaded Windows binary version of CMake-2.8.9 issued incorrect Fortran library linking commands while a version of CMake-2.8.9 that had been bootstrap-built on MinGW/MSYS/Wine issued the correct Fortran library linking commands. David and Bill are currently looking at a scripted build of ephcom to see whether they can replicate the issue on a Microsoft version of Windows. I have also given them detailed results from the good link and bad link build trees to help them figure out what is wrong with the downloaded Windows binary version of CMake-2.8.9. With the bootstrapped CMake-2.8.9, I got good test results for the current ephcom for MinGW corresponding to 4.5.2 and Wine-1.5.15. However, te_gen had run-time errors. Those were unlikely to be anything to do with the CMake bad generated link issue, but you never know, so I have been working hard on fixing those te_gen run-time issues in the last several day, and I just had complete success there. It turned out that MinGW has peculiarities in the way it handles Fortran common blocks, and the errors from that had being magnified by bugs (leading to segfaults and stackdumps) in the ephcom and te_gen error reporting system. I solved both issues by the appropriate ephcom and te_gen code changes, and the result is te_gen gave a good test result on MinGW/MSYS/Wine for the first time this morning! That result is identical to the same test run on Linux other than the expected difference in floating-point noise between the two results. So I am very happy at the moment, and I think these tests are a strong indication that there is nothing obviously wrong with the CMake-2.8.9 source code or the bootstrap build of that source code on MinGW/MSYS/Wine. However, the bad generated Fortran link issue with the downloaded binary Windows version of CMake-2.8.9 is still a concern. In an ideal world that should be producing the same good link commands for Fortran that the bootstrapped version does. If David and Bill cannot replicate the problem on Microsoft Windows or figure out what is going on from all the detailed build-tree results I gave them for the bad link and good link cases, I would be willing to do any additional experiments here they request to help see what is going wrong with the downloaded binary Windows version of CMake on Wine. 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] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 2012-10-23 17:41-0400 David Cole wrote: Short update: - I ran the script Alan sent me on a real Windows 7 machine, and didnot reproduce the problem while using the pre-built binary install of CMake 2.8.9 Thanks, David, for running that test which appears to rule out a compiler bug (for whatever C++ compiler was used to build the pre-built binary of CMake-2.8.9). So at this point a scenario where that C++ compiler uses new Windows API that Wine does not implement properly (while MinGW sticks to more common Windows API that Wine does implement correctly) is looking more likely. It appears the next step on your side is for Bill is to run his expert eye over the details he requested for my good build tree and bad build tree. He has just requested those details for the second time (which I just sent for the second time), and hopefully they will actually reach him this time. My guess is he will also want to compare those results with your own good build tree for the same test case. Meanwhile, I am going to attempt to repeat all my good PLplot, ephcom, and te_gen tests here using MinGW/gcc-version 4.7.0 (the version you get if you use the latest MinGW automatic installer and you request updates to the precanned versions). These tests, of course, will be for cmake bootstrapped with the MinGW/gcc-version 4.7.0. The motivation for these additional tests is to future-proof my results (i.e., make sure MinGW version is not critical to my recent success on the MinGW/MSYS/Wine platform). These tests if successful should also help to reduce concerns that there is any memory management issues in the CMake-2.8.9 source code. Of course, I will also try the same canned test you tried for this new MinGW version both for the bootstrapped CMake and the downloaded Windows binary version of CMake, but my expectation is the result will be the same (bootstrapped CMake generates the correct Fortran link command while the downloaded Windows binary version does not). But we will see. 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] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 2012-10-19 13:39-0400 Bill Hoffman wrote: On 10/19/2012 1:24 PM, Alan W. Irwin wrote: So far this morning there have been no takers, but I hope that changes since I am really stumped by CMake _intermittently_ not issuing the correct link command for libraries with no consistent pattern I can spot with regard to anything I change. Couple of things to try: run --trace on cmake and compare them. Maybe something odd is happening with your cmake variables. Also, look at the generated makefiles and find out what is different between the ones that work and the ones that don't. If this can not be reproduced by running a set command line (some script you write)... Thanks for those suggestions, Bill. The current status is I have sent a complete test case to David Cole who plans to run it when he has a chance this week on at least one Windows platform available to him. That test should show just how easy this issue is to replicate (or not). For that test case here, CMakes generates a bad link command for the epcomf Fortran library for the downloaded Windows binary version of CMake-2.8.9, but I have just discovered that a bootstrapped build of CMake-2.8.9 (using MinGW/MSYS for version 4.5.2 of gcc) generates the correct Fortran link command. I have attached the two relevant build.make files for you and David to look at. The diff between them shows a lot of noise due to different names for libraries used by downloaded versus bootstrapped CMake. I eliminated that diff noise as follows: wine@raven sed -e s?libephcom?ephcom?g -e s?libgnulliver?gnulliver?g -es?\.dll\.a?.lib?g /tmp/build.make |diff -au /tmp/bad_build.make - The result was --- /tmp/bad_build.make 2012-10-20 12:57:03.575441788 -0700 +++ - 2012-10-20 12:59:56.777968384 -0700 @@ -26,17 +26,14 @@ SHELL = /bin/sh # The CMake executable. -CMAKE_COMMAND = /Z/home/wine/newstart/cmake-2.8.9-win32-x86/bin/cmake.exe +CMAKE_COMMAND = /Z/home/wine/newstart/bootstrap_cmake/install_4.5.2/bin/cmake.exe # The command to remove a file. -RM = /Z/home/wine/newstart/cmake-2.8.9-win32-x86/bin/cmake.exe -E remove -f +RM = /Z/home/wine/newstart/bootstrap_cmake/install_4.5.2/bin/cmake.exe -E remove -f # Escaping for special characters. EQUALS = = -# The program to use to edit the cache. -CMAKE_EDIT_COMMAND = /Z/home/wine/newstart/cmake-2.8.9-win32-x86/bin/cmake-gui.exe - # The top-level source directory on which CMake was run. CMAKE_SOURCE_DIR = /z/home/wine/newstart/ephcom2_20121019 @@ -53,6 +50,7 @@ include bindings/f95/CMakeFiles/ephcomf.dir/flags.make bindings/f95/CMakeFiles/ephcomf.dir/ephcomf.f.obj: bindings/f95/CMakeFiles/ephcomf.dir/flags.make +bindings/f95/CMakeFiles/ephcomf.dir/ephcomf.f.obj: bindings/f95/CMakeFiles/ephcomf.dir/includes_Fortran.rsp bindings/f95/CMakeFiles/ephcomf.dir/ephcomf.f.obj: z:/home/wine/newstart/ephcom2_20121019/bindings/f95/ephcomf.f $(CMAKE_COMMAND) -E cmake_progress_report /Z/home/wine/newstart/ephcom2/build_dir/CMakeFiles $(CMAKE_PROGRESS_1) @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green Building Fortran object bindings/f95/CMakeFiles/ephcomf.dir/ephcomf.f.obj @@ -81,8 +79,11 @@ dll/ephcomf.dll: dll/ephcom.lib dll/ephcomf.dll: dll/gnulliver.lib dll/ephcomf.dll: z:/home/wine/newstart/ephcom2_20121019/bindings/f95/ephcomf_mingw.def +dll/ephcomf.dll: bindings/f95/CMakeFiles/ephcomf.dir/objects1.rsp @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red --bold Linking Fortran shared library ../../dll/ephcomf.dll - cd /Z/home/wine/newstart/ephcom2/build_dir/bindings/f95 /z/home/wine/newstart/MinGW/bin/gfortran.exe /z/home/wine/newstart/ephcom2_20121019/bindings/f95/ephcomf_mingw.def -shared -o ../../dll/ephcomf.dll $(ephcomf_OBJECTS) $(ephcomf_EXTERNAL_OBJECTS) ../../dll/ephcomfc.lib ../../dll/ephcomc.lib ../../dll/ephcom.lib ../../dll/gnulliver.lib + cd /Z/home/wine/newstart/ephcom2/build_dir/bindings/f95 /Z/home/wine/newstart/bootstrap_cmake/install_4.5.2/bin/cmake.exe -E remove -f CMakeFiles/ephcomf.dir/objects.a + cd /Z/home/wine/newstart/ephcom2/build_dir/bindings/f95 /z/home/wine/newstart/MinGW/bin/ar.exe cr CMakeFiles/ephcomf.dir/objects.a @CMakeFiles/ephcomf.dir/objects1.rsp + cd /Z/home/wine/newstart/ephcom2/build_dir/bindings/f95 /z/home/wine/newstart/MinGW/bin/gfortran.exe /z/home/wine/newstart/ephcom2_20121019/bindings/f95/ephcomf_mingw.def -shared -o ../../dll/ephcomf.dll -Wl,--out-implib,../../dll/ephcomf.lib -Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/ephcomf.dir/objects.a -Wl,--no-whole-archive ../../dll/ephcomfc.lib ../../dll/ephcomc.lib ../../dll/ephcom.lib ../../dll/gnulliver.lib # Rule to build all files generated by this target. bindings/f95/CMakeFiles/ephcomf.dir/build: dll/ephcomf.dll You can see the link commands are very different, but also it is intriguing there are other differences as well between CMake results generated with two
[cmake-developers] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
if that will make any difference. (The bootstrapped version of CMake-2.8.9 that I have now only works with version 4.6.2 of the compilers, i.e, the compiler version it was built with.) So this has been a long, sad, and continuing saga where I still haven't pinned down exactly why on some occasions CMake generates incomplete link commands for Fortran libraries. However, my feeling at this stage is the complete or incomplete Fortran link commands are not caused by anything I am doing, but are instead caused by some memory management issue for CMake that sometimes clobbers the variables that control whether the linking is for a module or library. To test that hypothesis further, I am willing to run a gdb session (gdb.exe is available as one of the MinGW executables) on CMake while it is executing to help see what is going on, but I would need some help from experts here with navigating my way throught the many different CMake routines and to find exactly what variables affect the module versus library style of Fortran linking. Although it is hard for me to imagine some Wine-1.5.15 bug intermittently affecting whether CMake generates a full or incomplete link command for Fortran libraries, I guess that is a possible explanation of what I am seeing as well. So that raises the important question of what is the status of MSYS Makefiles testing on proprietary Windows platforms? I know from what Bill has said recently that MSYS Makefiles builds are tested regularly on a couple of machines, but do those tests include Fortran? And if so, what version of the MinGW gfortran compiler is being tested, and does that testing include attempts to link Fortran executables with Fortran libraries? (Note the incomplete linking is normally detected by such attempts. Alternatively you could test whether both *.dll and *.dll.a files are being produced by the link step.) Does anyhow here have lots of MinGW/MSYS Windows experience with gfortran so they are in a position to comment on the reliability of the link commands for Fortran libraries generated by cmake -G MSYS Makefiles for that platform? This generated Fortran link command issue has already given me several miserable days so any help you could give me with this issue would be much appreciated. 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] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 2012-10-19 02:18-0700 Alan W. Irwin wrote: So this has been a long, sad, and continuing saga where I still haven't pinned down exactly why on some occasions CMake generates incomplete link commands for Fortran libraries. However, my feeling at this stage is the complete or incomplete Fortran link commands are not caused by anything I am doing, but are instead caused by some memory management issue for CMake that sometimes clobbers the variables that control whether the linking is for a module or library. Let me marshall the arguments further concerning this hypothesis now that I have had some sleep. The issue appears for the Windows binary versions of CMake-2.8.5, 2.8.8, and 2.8.9, and I think (but cannot recall clearly) that it also occurred at least once for the bootstrapped build of CMake-2.8.9. Of course, there could be a long-term memory-management issue for the code that generates the Fortran link command for the MSYS Makefiles generator that affects all recent CMake versions. Later today I will be able to say more about that when I try another bootstrapped build based on my present (4.5.2) MinGW version. But regardless of whether bootstrapped builds are more reliable in this respect, the symptoms of memory management issues are often intermittent and depend on all sorts of implementation details so I expect the symptoms for the bootstrapped version could be different than the Windows binary version which was presumably built with a Windows compiler rather than MinGW compiler and also different between MinGW versions. The issue occurred first not only for the full te-gen build system, but also for a completely simplified version of it. For what it is worth those simplifications were implemented by removing all sorts of te_gen build-system CMake code with constructs like if(whatever) (many CMake commands) endif(whatever) where whatever was not defined. I don't know the CMake internal implications of code that is removed this way, but I doubt the result is identical to actually removing the code from the file since I got the bad link command issued for the exact te_gen equivalent (only the names were changed) of my simple test case, but never for that simple test case. The issue is always specific to the generation of the Fortran link command for the MSYS Makefiles generator. If it is some wine-1.5.15 problem why does the intermittent problem always occur just for that limited case? Remember, for the same platform I did a bootstrap build of CMake with no obvious issues, and I did very extensive testing of C results (with complete linking commands always issued for the C libraries involved) for ephcom2 with no obvious issues. Also, when the Fortran link command generated by CMake was working, I did a modest (less than 1-minute of cpu time) but successful test of the Fortran run-time with the ephcomf Fortran library. In contrast, there _are_ run-time issues for MinGW gfortran-4.6.2 revealed by the extensive Fortran run-time testing (up to one hour cpu time when it is working) I get with the te_gen package. But I doubt the generation of the Fortran library link command by CMake itself depends in the slightest on Fortran run-time issues so long as a platform is capable of building a simple Fortran test application that can be successfully run (which is the case for all variants I have tried so far). I suspect that no current test platforms for the MSYS Makefiles case include a check that the Fortran link command for libraries actually generates both a *.dll and *.dll.a form of the library. Would it be straightforward to arrange such a test? Perhaps I just haven't run my simple test case (for a Hello World Fortran library) often enough to find a case where it didn't generate the *.dll.a form of the library Thus, routine simple testing for this potential issue might turn up some (intermittent) instances where it occurs. To test that hypothesis further, I am willing to run a gdb session (gdb.exe is available as one of the MinGW executables) on CMake while it is executing to help see what is going on, but I would need some help from experts here with navigating my way throught the many different CMake routines and to find exactly what variables affect the module versus library style of Fortran linking. Although it is hard for me to imagine some Wine-1.5.15 bug intermittently affecting whether CMake generates a full or incomplete link command for Fortran libraries, I guess that is a possible explanation of what I am seeing as well. So that raises the important question of what is the status of MSYS Makefiles testing on proprietary Windows platforms? I know from what Bill has said recently that MSYS Makefiles builds are tested regularly on a couple of machines, but do those tests include Fortran? And if so, what version of the MinGW gfortran compiler is being tested, and does that testing include attempts to link Fortran executables with Fortran libraries? (Note
Re: [cmake-developers] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 2012-10-19 13:08-0400 David Cole wrote: Hi Alan, Can you write a script that would reproduce the problem for us here if we ran the script? (Even if the project that it has to build is complex...) Thanks for that offer, and yes I do have the complete builds scripted by bash (see comment below) for both te_gen and ephcom. te_gen is a complicated test case because it depends on ephcom. But fortunately I currently have the generated Fortran link command issue showing up for ephcom which considerably simplifies what I need to send you. So let me simplify the ephcom build script as much as possible for you (while it still demonstrates the bad symptoms for me), and I hope to get back to you off-list ASAP with a complete example. There is nightly testing using MSYS Makefiles with GNU 4.5.0 with Fortran: http://open.cdash.org/buildSummary.php?buildid=2618838 and all the Fortran tests pass: http://open.cdash.org/viewTest.php?buildid=2618838filtercount=1showfilters=1field1=testname/stringcompare1=63value1=Fortran Are any of those 5 separate tests sensitive to an incomplete linking statement being issued for Fortran libraries? That won't generate any errors until an attempt is made to link a Fortran application with that badly linked library. If the answer is these tests are sensitive to the issue, then I will try (later today after I have sent you the ephcom script) the 4.5.0 version of MinGW myself to be as consistent as possible with these tests. Of course, my experience is that simple tests for this issue don't show anything, but my simple tests were not extensive so if the above actually do a lot of such simple tests relevant to this issue, that would be useful to know. From the way you describe things here, it sounds like you're switching back and forth between versions of CMake, versions of gfortran, and also modifying CMake code to narrow down and come up with a simple case, and other actions ... all of which may have some interactions with cached variable values. I don't think there's a memory clobbering issue going on here (but there could be, I suppose), but rather more likely some setting that gets stuck in the CMakeCache file but is then not applicable after you make a code change in CMake, but the value is still there in the cache, and maybe unexpectedly influences what is generated. (This is all just suspicion and speculation, but reasonable I think.) You especially should always do a fully clean re-build if you change compilers, even if it's just one version number. Clean rebuilds are not the issue since my bash scripts for running each of these test cases always include a command to remove the build tree before doing any test in a separate initially empty build tree. I didn't use a script for the simple example, but in that case as well I was alway careful to make a clean start with an initially empty build tree. If it works for the simple case, but not for the complex one, then some difference between those projects is the thing that triggers the problem. It would be good using fully clean re-builds to give exact steps to reproduce the problem in the simplest case. Although reproducing it with a more complex case might certainly be more useful than spending tons and tons of time trying to simplify it. Again: Can you write a script that would reproduce the problem for us here if we ran the script? (Even if the project that it has to build is complex...) Yes, and I will try to get back to you ASAP with that. Thanks, again, for that offer! 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] ReactOS: Important filed bug reports went to backlog en masse
On 2012-08-13 06:54-0400 David Cole wrote: This was actually my exact intent (to re-involve the original reporters via the notification system, since nobody else has picked up on the bugs enough to assign them), and this was just step 1. The bug tracker's roadmap page and what bugs are actually assigned to active CMake developers are two of the most important pieces of information we can get from the bug tracker. Having a bunch of bugs in there that nobody has ever looked at is just as useless as allowing emails on the list to fall through the cracks without any responses. I intend to do the same thing with bugs that are actually assigned to developers that have not been updated in the last 3 or 4 months. (If it hasn't been updated, then it's not really active...) If you care about a bug that's assigned to you, and want to get it fixed in CMake 2.8.10, please update it by adding a note by setting the Target Version field and putting it on the roadmap page. The ones that people really care about will be brought back. If nobody cares about an issue, then it's not really an issue. The bug tracker is an imperfect measurement of care, but it's one of the closest proxies that we have. Thanks for your comments, My comment is this is a really touchy political issue. To be a devil's advocate, backlogging is generally a slap in the face to those of us who have made an effort to present a careful, well-documented bug report which often includes a patch that fixes the issue. My impression is a lot of such high-quality bug reports are still ignored because of lack of resources to even make decisions on whether the proposed fix is acceptable or not, and this lack of resources to do decision making has now been formalized with the backlogging idea. Why should we try to make high-quality bug reports for CMake if we have to periodically do additional and completely non-productive work to justify not throwing our prior good effort on the trash heap (i.e., backlog)? Note, these are devil's advocate points, and I do personally understand the necessity of a measure like this to keep your limited bug-fixing resources focussed on issues where the bug reporter really cares about the outcome, and also to achieve higher signal-to-noise ratio in the bugtracker for issues that are not backlogged. But I would make sure that the period of time before a bug is backlogged is generous (at least a year), and I would advertise that period of time up front on the bugtracker as part of a notice that carefully justifies the measure and which also warns the would-be bug reporter that it is normally a long-term commitment to keep his bug report out of the trash heap if his bug report does not attract the attention of a CMake developer (regardless of whether they are salaried by Kitware or volunteer). Also, this whole issue is a clear sign that CMake does not have enough _organized_ bug report evaluation resources at the moment (for example, to simply test and evaluate all patches that appear on the bug tracker). My impression from all the traffic on this list is the volunteer development community for CMake is growing rapidly, but perhaps you (David) might be able to harness some of that volunteer energy by periodically giving a report on the numbers of unresolved bugs on the bugtracker and asking for volunteers to help with evaluation of those. 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] ReactOS: Important filed bug reports went to backlog en masse
On 2012-08-13 17:23-0400 David Cole wrote: I realize that this is a touchy subject, and tried very hard to word my messages that went along with this action to make it very clear that putting a bug into the 'backlog' is not in the least bit permanent. I think the politics of this could be considerably eased if you also put a prominent announcement of what the backlog classification means on the first page of the bug tracker. 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] Documented property IMPORTED_LOCATION does not exist
On 2012-01-25 08:14-0500 Brad King wrote:
On 1/25/2012 1:50 AM, Michael Wild wrote:
So, to fix your code, use IMPORTED_LOCATION_NOCONFIG.
Actually just use LOCATION or LOCATION_${CONFIG} for some CONFIG:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LOCATION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LOCATION_CONFIG
They will tell you where to find the target file for any target,
including imported targets. The IMPORTED_... properties are really
meant for *setting* to tell CMake something, not for *getting*
information from CMake.
That important distinction between IMPORTED_LOCATION and LOCATION
needs clarification in the documentation so even experienced CMake
users like me are not mislead.
For example, under PROPERTIES ON TARGETS, the IMPORTED_LOCATION
documentation uses the phrase this is a lot implying the property
exists (i.e., has been reliably set) for any given imported target.
Michael's original response to me said he used IMPORTED_LOCATION all
the time with no issues. So he apparently configures his software
builds in some way (is that because you always set CMAKE_BUILD_TYPE,
Michael?) to actually make the exported modules contain
IMPORTED_LOCATION, while for PLplot I just build it with no specified
CMAKE_BUILD_TYPE so only IMPORTED_LOCATION_NOCONFIG (but not
IMPORTED_LOCATION) is set in the exported modules.
Is that the real issue here? Should exporting a target automatically
set both IMPORTED_LOCATION_NOCONFIG _and_ IMPORTED_LOCATION for all
cases (e.g., when you haven't set CMAKE_BUILD_TYPE as in my particular
PLplot build)?
Of course, if I had read further in the documentation to LOCATION, it
is made clear there that is the READ-ONLY one that should be used for
most generality.
But I didn't read further since the IMPORTED_LOCATION section implied
that property would be set reliably for imported targets, and
certainly Michael's original response seemed to confirm that as well,
i.e., his experience seemed to be consistent with that documentation.
So it appear to me the choices are to set IMPORTED_LOCATION in export
modules reliably regardless of how CMAKE_BUILD_TYPE is set (or not
set) or to change the documentation of IMPORTED_LOCATION to indicate
it is not always reliably set for imported targets and urge the reader
to use LOCATION instead.
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] Documented property IMPORTED_LOCATION does not exist
On 2012-01-24 06:28+0100 Michael Wild wrote:
On 01/24/2012 05:50 AM, Alan W. Irwin wrote:
The documentation you get from
cmake --help-full
refers to the IMPORTED_LOCATION property as one of the more important
ones set for imported targets. I have to agree that location is the
most important property for imported targets, but the name appears to
be wrong for the documentation of this property!
After screwing around for a while trying to use the above
property for my imported targets, I discovered (by guessing) that the
name of a property that actually does give the location information is
IMPORT_LOCATION, not IMPORTED_LOCATION. For what it is worth,
IMPORT_LOCATION works for an imported library, and I haven't tried
this on imported executables. (By the way, LOCATION works as well, but
that appears from the documentation to be a left-over from CMake 2.4
which is why I tried to get IMPORTED_LOCATION to work and when that
failed, switched to the currently undocumentated IMPORT_LOCATION.)
I find IMPORTED_LOCATION is mentioned in the following
places in the cmake-2.8.6 source tree:
software@raven find cmake-2.8.6 -print0 -type f \
|xargs -0 grep -l IMPORTED_LOCATION
cmake-2.8.6/ChangeLog.txt
cmake-2.8.6/Modules/FindQt4.cmake
cmake-2.8.6/Tests/ExportImport/Import/A/CMakeLists.txt
cmake-2.8.6/Tests/SimpleInstall/CMakeLists.txt
cmake-2.8.6/Tests/SimpleInstallS2/CMakeLists.txt
cmake-2.8.6/Source/cmTarget.cxx
cmake-2.8.6/Source/cmAddExecutableCommand.h
cmake-2.8.6/Source/cmAddLibraryCommand.h
cmake-2.8.6/Source/cmExportBuildFileGenerator.cxx
cmake-2.8.6/Source/cmExportInstallFileGenerator.cxx
A similar search for IMPORT_LOCATION found nothing at all!
However, I spot-checked cmake-2.8.6/Source/cmTarget.cxx, and all those
mentions of IMPORTED_LOCATION appear to be documentation strings
rather than executable code, and I was unable to find why
IMPORTED_LOCATION does not work for me while IMPORT_LOCATION does. So
this needs someone who is familiar with the CMake code to figure out
what the actual problem is here, and to decide whether a fix to the
documentation strings is all that is required or whether some deeper
change needs to be made.
Alan
IMPORTED_LOCATION works just fine for me. Also IMPORT_LOCATION, as you
call it, is not referenced once in the whole CMake source, while
IMPORTED_LOCATION is, and not only as a documentation string as you
claim.
Hi Michael:
Thanks for your response.
Since you cannot verify the issue, then the most likely reason is
there is some difference between your and my CMake version, minimum
CMake version (which affects policy decisions), and hardware/software
platform. Could you be more specific about those constraints in your
case?
Just to be sure I was reporting a clean result, I started with a
fresh bootstrap build and install of CMake-2.8.7 that I did on my
Debian Squeeze platform. I then built and installed PLplot (which
specifies cmake_minimum_required(VERSION 2.8.2 FATAL_ERROR) from
scratch using that version of cmake.
I have attached the resulting export module files that are installed
as a result of that PLplot install.
I then checked imported target properties with the following CMake test script
(which is also attached for convenience).
project(test_export NONE)
cmake_minimum_required(VERSION 2.8.2 FATAL_ERROR)
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR} )
include(export_plplot OPTIONAL RESULT_VARIABLE IF_PLOT)
if(IF_PLOT)
get_target_property(test_loc1 _plplotcmodule IMPORT_LOCATION)
message(STATUS IMPORT_LOCATION = ${test_loc1})
get_target_property(test_loc2 _plplotcmodule IMPORTED_LOCATION)
message(STATUS IMPORTED_LOCATION = ${test_loc2})
else(IF_PLOT)
message(WARNING IF_PLOT = ${IF_PLOT})
endif(IF_PLOT)
And here was the result when cmake was invoked from a sub-directory
of the one containing the above CMakeLists.txt and the export files.
software@raven cmake ..
-- IMPORT_LOCATION =
/home/software/plplot_svn/installcmake/lib/python2.6/site-packages/_plplotcmodule.so
-- IMPORTED_LOCATION = test_loc2-NOTFOUND
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/cmake_test/build_dir
Note, _plplotcmodule is one of the shared objects generated by PLplot
for our python bindings, but if you look at the export files, there
doesn't seem to be anything done differently for _plplotcmodule compared
to other PLplot library targets, and also I assure you
the result for IMPORT_LOCATION is correct.
So the above simple script cleanly shows the issue for 2.8.7.
IMPORT_LOCATION is an imported target property with the correct value
while IMPORTED_LOCATION is not found.
If you try the same test script with the same exported files, do you
get a different result? If you still have trouble verifying the above
result, then please also try CMake-2.8.7 to see whether that version
is the source of the issue.
One obvious possibility is there is something wrong with the attached
PLplot export files.
They are generated by the PLplot build
[cmake-developers] Documented property IMPORTED_LOCATION does not exist
The documentation you get from cmake --help-full refers to the IMPORTED_LOCATION property as one of the more important ones set for imported targets. I have to agree that location is the most important property for imported targets, but the name appears to be wrong for the documentation of this property! After screwing around for a while trying to use the above property for my imported targets, I discovered (by guessing) that the name of a property that actually does give the location information is IMPORT_LOCATION, not IMPORTED_LOCATION. For what it is worth, IMPORT_LOCATION works for an imported library, and I haven't tried this on imported executables. (By the way, LOCATION works as well, but that appears from the documentation to be a left-over from CMake 2.4 which is why I tried to get IMPORTED_LOCATION to work and when that failed, switched to the currently undocumentated IMPORT_LOCATION.) I find IMPORTED_LOCATION is mentioned in the following places in the cmake-2.8.6 source tree: software@raven find cmake-2.8.6 -print0 -type f \ |xargs -0 grep -l IMPORTED_LOCATION cmake-2.8.6/ChangeLog.txt cmake-2.8.6/Modules/FindQt4.cmake cmake-2.8.6/Tests/ExportImport/Import/A/CMakeLists.txt cmake-2.8.6/Tests/SimpleInstall/CMakeLists.txt cmake-2.8.6/Tests/SimpleInstallS2/CMakeLists.txt cmake-2.8.6/Source/cmTarget.cxx cmake-2.8.6/Source/cmAddExecutableCommand.h cmake-2.8.6/Source/cmAddLibraryCommand.h cmake-2.8.6/Source/cmExportBuildFileGenerator.cxx cmake-2.8.6/Source/cmExportInstallFileGenerator.cxx A similar search for IMPORT_LOCATION found nothing at all! However, I spot-checked cmake-2.8.6/Source/cmTarget.cxx, and all those mentions of IMPORTED_LOCATION appear to be documentation strings rather than executable code, and I was unable to find why IMPORTED_LOCATION does not work for me while IMPORT_LOCATION does. So this needs someone who is familiar with the CMake code to figure out what the actual problem is here, and to decide whether a fix to the documentation strings is all that is required or whether some deeper change needs to be made. 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] branch HandleCMAKE_CXX_COMPILER_ARG1InEclipse for 2.8.6 ?
On 2011-10-01 20:13+0200 Alexander Neundorf wrote: On Saturday 01 October 2011, David Cole wrote: Brad and Bill and I will look at this Monday. We are closing in on the final 2.8.6 release. If we take changes Monday, we'll merge them, await the dashboard results on Tuesday morning, and then build the final 2.8.6. If we take no changes, I'll build 2.8.6 on Monday. You must admit, this fix affects an awfully small percentage of the total CMake user base... So we may not take it. But, since it's so small, we may. That's what I thought too :-) How many last minute changes to accept appears to be a universal issue for releasing software. I have turned more and more conservative on this issue as I gained experience with the downsides of such changes for other projects. For me it now boils down to these questions: 1. If there is a high upside (many users benefit) to the last-minute change, then why aren't you delaying the release to make sure the change is properly tested? 2. If there is a low upside to the last-minute change (only a few users benefit), can you bet your project's reputation that there is no downside for all users or would it be better to wait for the next release cycle to gain more testing of the change? CMake developers will obviously have to make up their own mind on this issue for their releases, but as you can tell from the way those questions are posed, I almost always discourage last-minute changes in releases for projects where I am one of the developers. 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-2.8.5 build error on the MinGW/MSYS/wine platform
Hi Clint: There are questions for you below concerning where system header information in the Wine environment is located. On 2011-09-15 14:34-0700 Alan W. Irwin wrote: Of course, Wine _might_ be at fault here for not #defining _SSIZE_T_DEFINED when ssize_t is typedefed. But is that a standard that you expect to be followed on all platforms or a Microsoft Windows idiosyncrasy that more robust CMake code would not have to worry about? I looked further, and the _Linux_ build of wine does have the following in the install tree $prefix/include/wine/msvcrt/sys/types.h:#define _SSIZE_T_DEFINED where $prefix is my prefix for my Linux wine install. The context for that #define is as follows: #ifndef _SSIZE_T_DEFINED #ifdef _WIN64 typedef __int64 ssize_t; #else typedef int ssize_t; #endif #define _SSIZE_T_DEFINED #endif So _SSIZE_T_DEFINED should be unequivocally #defined by the above if (i) the information in msvcrt/sys/types.h is available in the wine environment and (ii) in a location that CMake expects in that free Windows environment, and (iii) it is in the #include chain for the build of, e.g., archive_read.c.obj. Following the general Wine directions, I put $prefix/bin on my Linux PATH, then run winecfg, and everything seems to work fine from within the wine environment (e.g, the build of ephcom-2.0.2, and the build of CMake-2.8.5) except for the #define of _SSIZE_T_DEFINED. Clint, this next question is mostly directed to you since you have some Wine platform experience. What can I do further to diagnose what is wrong with my Wine environment such that _SSIZE_T_DEFINED is not #defined? I have searched throughout my .wine prefix directory (created by winecfg), and there are lots of dll's in that directory tree (including .wine/drive_c/windows/system32/msvcrt.dll), but there doesn't seem to be any header files in that directory tree at all. So how does winecfg set up access to the headers in $prefix/include? The cmake output is ambiguous about where it finds types.h. All it says in that regard is -- Looking for sys/types.h -- Looking for sys/types.h - found and for all I know that could be referring to some other header file than $prefix/include/wine/msvcrt/sys/types.h. In any case at the key moment at make time when the cmake build needs access to the above #define _SSIZE_T_DEFINED in that file, that file is not in the #include chain so _SSIZE_T_DEFINED is not #defined. Although my present build of 2.8.5 with the -D_SSIZE_T_DEFINED workaround wiped out my previous experiments with the failing build of 2.8.3, I did save the actual gcc command that was failing at the time. It was the following: /Z/home/wine/newstart/MinGW/bin/gcc.exe -DCURL_STATICLIB -DLIBARCHIVE_STATIC -DHAVE_CONFIG_H -I/Z/home/wine/newstart/cmake/build_dir/Utilities/cmlibarchive -I/Z/home/wine/newstart/cmake/build_dir/Utilities -I/z/home/software/cmake/cmake-2.8.3/Utilities -I/z/home/software/cmake/cmake-2.8.3/Utilities/cmbzip2 -I/z/home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive -o CMakeFiles/cmlibarchive.dir/archive_read.c.obj -c /z/home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive/archive_read.c Notice there are no -I options to help find system headers such as $prefix/include/wine/msvcrt/sys/types.h. In any case that header does not appear to be in the #include chain for the CMake build, but I will attempt to confirm that further tomorrow with a repeat of my gcc -E -dD run (this time for 2.8.5) without the -D_SSIZE_T_DEFINED workaround. Please let me know any other experiments I should be trying to pin down exactly why $prefix/include/wine/msvcrt/sys/types.h is not in the #include chain for the archive_read.c.obj build. Sorry it is taking so long to unpeel each layer of this onion, but debugging wine headers is completely new to me so I am having trouble knowing where to look for information. 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-09-16 14:48-0400 David Cole wrote: The information in this CMake bug tracker issue suggests that this is *completely* a MinGW / MSYS regression, and not really a cmake issue... http://public.kitware.com/Bug/view.php?id=12418 According to the latest note there, just added: With mingw 4.5.2 it works, but mingw 4.6.1 fails with this error. Nothing to do with CMake or Wine at all. I would call this one a very recently introduced mingw problem. Hmm. Brad and Bill just got through assuring me repeatedly there is no problem with the most recent MinGW/MSYS build of CMake on Microsoft Windows. Of course, they could be up against the case where some Microsoft platforms work and others do not. Anyhow, it appears this guy got the same broken build on some Microsoft platform that I am getting on Wine. It appears the next obvious step is to attempt replicating that guy's broken-build results with the most recent MinGW/MSYS on whatever Microsoft platform he was using. Note, I would be quite relieved (since I am way beyond my depth here) if one of you could find a way verify that broken build on Microsoft Windows. That means Wine is just a distraction to the discussion, and I can let some expert Kitware employee deal with this issue who presumably has a large desire to have builds of CMake with recent MinGW/MSYS actually work on all Microsoft Windows platforms. 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-09-16 16:46-0400 Brad King wrote: On 9/16/2011 4:40 PM, Brad King wrote: As expected upstream libarchive already fixed this: http://code.google.com/p/libarchive/source/detail?r=3649 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8dfe74c3 Hi Brad, Bill, and Dave: As anticipated, that version of the patch (for cmake-2.8.5) works for me on Wine. @ Brad: Thanks for trying my suggestion that older MinGW/MSYS installers might not be so good at updating to get you the latest version of MinGW/MSYS. @ Bill: Thanks for the encouragement to keep pursuing this issue. @ Dave: Thanks for noticing the bug report that had the same broken build issue that I was having on Wine which was the key breakthrough in my opinion. This has been a tough one for me because (i) my Wine environment is slow (each cmake build takes more than an hour because of a nasty 1-second command startup latency issue for each command run by cmake and make), (ii) too many possibilities (Wine, CMake, or MinGW) for the source of the issue, and (iii) many preprocessor directives that made it virtually impossible to eyeball the code to see what was wrong (although gcc -E -dD eventually came to the rescue there). Anyhow, I am very glad that the CMake code finally has a solution for this issue! 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-09-14 21:54-0700 Alan W. Irwin wrote: On 2011-09-01 05:45-0700 Alan W. Irwin wrote: On 2011-08-28 14:34-0400 Bill Hoffman wrote: Can you try and build CMake 2.8.4, then 2.8.3 and see what happens? [...]I thought wine-1.3.27 might have been to culprit, but it turns out I was just now able to generate the same cmake-2.8.5 build error with MinGW/MSYS/wine-1.3.26. On that same platform, and with the binary version of cmake-2.8.5 (which worked very well for me with ephcom2) I will now attempt builds of cmake-2.8.4 and earlier to see whether the cmake-2.8.5 build error I am getting is a cmake-source code regression for this fixed platform. There is exactly the same build error when attempting to build cmake-2.8.4 and 2.8.3 using binary cmake-2.8.5 and when attempting to build 2.8.3 with binary cmake-2.8.3. I have built cmake-2.8.3 successfully before with binary cmake-2.8.3 on a MinGW/MSYS/wine platform so this appears to be some incompatibility of cmake builds with either (i) recent versions of wine or (ii) recent versions of MinGW/MSYS. To eliminate the latter possibility, could somebody please try to build cmake with the MSYS Makefiles generator on Windows? It literally is only a 5 minute download to install the required MinGW/MSYS these days (see below). That automatic installer (available at http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/) literally takes about 5 minutes to download and install all of MinGW/MSYS on wine, and I am sure that it would even be faster on Windows. Is there anybody game to try the build of cmake on Windows using the latest MinGW/MSYS stack you install with the automatic installer? 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-09-15 09:22-0400 Brad King wrote: On 9/15/2011 4:12 AM, Alan W. Irwin wrote: To eliminate the latter possibility, could somebody please try to build cmake with the MSYS Makefiles generator on Windows? We have a dashboard for this. I build that all the time on my own machine too. Just in case, I updated the toolchain: mingw-get install gcc mingw-get install g++ mingw-get install gfortran mingw-get install binutils CMake 2.8.5 builds the latest CMake master with no errors. That sounds definitive, but I don't really trust MinGW/MSYS installers (since that is alpha software) to do the right thing with updates. It wasn't that long ago that that functionality was completely broken. Instead, what I did was a complete install with mingw-get-inst-20110802, and I hope you will try that as well to completely eliminate this possibility. 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-09-15 09:27-0400 Bill Hoffman wrote: On 9/15/2011 4:12 AM, Alan W. Irwin wrote: That automatic installer (available at http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/) literally takes about 5 minutes to download and install all of MinGW/MSYS on wine, and I am sure that it would even be faster on Windows. Is there anybody game to try the build of cmake on Windows using the latest MinGW/MSYS stack you install with the automatic installer? I just built with the most recent MinGW makefile build, and it works. MinGW Makefiles is quite different than the MSYS Makefiles builds I am doing. Also, note my comments to Brad about what constitutes the latest MinGW/MSYS. I am pretty sure from Brad's MSYS Makefiles result that all is well with MSYS Makefiles builds of CMake on Microsoft Windows, but being absolutely sure is even better than pretty sure which is why I asked him to try replicating exactly the same MinGW/MSYS install steps that I did. Also, we have dashboards that do mingw and msys. See these builds: amber12.kitware Win32-mingw-gcc-4.5 amber12.kitware Win32-msys-gcc-4.5 For the msys one you appear to be referring to http://www.cdash.org/CDash/iphone/buildsummary.php?buildid=1039633. There is no identification there of the exact MinGW/MSYS being used for that build. Furthermore, the cmake time is 6 seconds and the build time is 0 seconds (same start and end time). So it appears to be an update of a previous build rather than a build from scratch. That makes sense from the perspective of saving a lot of computer time on the machine doing the build, but it is not the same as the build from scratch that I am doing here. Again, it is the difference between being pretty sure and absolutely sure there is no trouble with MSYS Makefiles builds of CMake on Microsoft windows. Sounds to me it is the windows.h that comes with wine maybe. Really you should just debug this and find the issue. Run make help in Utilities/cmlibarchive/libarchive. You will see file.i. targets you want this one: archive_read.i That will create a cpp processed version of the file. Then you need to grep around the files that are included and find the problem. I have avoided this step because I have been frankly intimidated by the size and complexity of the CMake code and my lack of (free) Windows platform knowledge. However, now you have encouraged me to try debugging it, I realize there is an even easier way to track down what is going on with the macros in question. That is, find the exact g++ command that failed from the VERBOSE=1 ouput, then repeat that by hand using the g++ -E -dD (or -dM) options. More later after I give that idea a try. 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-08-27 16:22-0700 Alan W. Irwin wrote: If you compare the types of archive_read_data and archive_read_data_into_buffer in archive_read.c versus archive.h, the *.c versions are ssize_t archive_read_data(struct archive *_a, void *buff, size_t s) int archive_read_data_into_buffer(struct archive *a, void *d, ssize_t len) while the *.h versions are __LA_DECL __LA_SSIZE_T archive_read_data(struct archive *, void *, size_t); __LA_DECL int archive_read_data_into_buffer(struct archive *, void *buffer, __LA_SSIZE_T len); So it appears on the MinGW/MSYS/wine platform at least that something is screwed up with the __LA_DECL and/or __LA_SSIZE_T macros. Hi Bill: As promised, I am now following up with -E -dD information (for the case of binary cmake-2.8.3 building cmake-2.8.3, but I assume the results would be identical for 2.8.4 and 2.8.5 since I got the same build errors for them). This combination of options really does the job, and I wish I had thought of them sooner. From the above __LA_DECL must have an empty #define, and __LA_SSIZE_T must be #defined to ssize_t to avoid the build error. Also, the above declarations of the functions occur on lines 308 and 407 of /home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive/archive.h -dD output says the following concerning __LA_DECL prior to lines 308 and 409 (it was changed later on, but that is not relevant) # 98 z:/home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive/archive.h #define __LA_DECL So that shows the desired empty result which avoids any build error from this cause. However, I was surprised the whole thicket of preprocessing directives just above line 98 in that file (which #define __LA_DECL to different values) was somehow avoided. -dD output say the following concerning __LA_SSIZE_T The second #define after # 54 z:/home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive/archive.h is #define __LA_SSIZE_T long which is inconsistent with the ssize_t function type for archive_read_data in archive.c which causes the build error. The relevant preprocessing code after line 54 is #define __LA_INT64_T__int64 # if defined(_SSIZE_T_DEFINED) # define __LA_SSIZE_T ssize_t # elif defined(_WIN64) # define __LA_SSIZE_T__int64 # else # define __LA_SSIZE_Tlong # endif The -dD results show that _SSIZE_T_DEFINED is not #defined, allthough they do show the following: #define _SSIZE_T_ typedef int _ssize_t; typedef _ssize_t ssize_t; Furthermore, they show that _WIN64 is not #defined (which makes sense since my platform is 32-bit wine on a 64-bit hardware platform (amd64)). But the point is both the __int64 and long result would cause a broken build because ssize_t is typedef'ed to int on (32-bit) wine. So in sum, it looks like the CMake code avoids a broken build on wine (and other platforms with ssize_t typedef'ed to int) only if _SSIZE_T_DEFINED is always #defined. I then tried export CFLAGS='-O3 -D_SSIZE_T_DEFINED' for a build from scratch of cmake-2.8.5 using cmake binary 2.8.5, and it worked with no errors or warnings! It is good to know that workaround is available for the cmake build on wine (presumably regardless of the x in cmake-2.8.x). I doubt very much though that I will have to be concerned with that workaround for builds of other software that is not as complicated as the CMake build. Of course, Wine _might_ be at fault here for not #defining _SSIZE_T_DEFINED when ssize_t is typedefed. But is that a standard that you expect to be followed on all platforms or a Microsoft Windows idiosyncrasy that more robust CMake code would not have to worry about? What I mean by that comment is the following. The current situation is the function and argument types in cmake-2.8.x/Utilities/cmlibarchive/libarchive/*.c files do not use the same macro-based approach as that used in cmake-2.8.x/Utilities/cmlibarchive/libarchive/archive.h for defining the types and arguments of functions. That seems like an accident waiting to happen (and, in fact, that accident has already happened on wine.) Perhaps there is some reason for this fundamental inconsistency in the definitions of the function types and arguments in the libarchive code, but I don't understand what that reason might be. I know virtually nothing about Windows platforms. So if you think it should be an expected standard, could you advise me where _SSIZE_T_DEFINED is #defined for Microsoft Windows so I could advise Wine to do the same in their equivalent header? I could find nothing official from Microsoft about _SSIZE_T_DEFINED in a google search. Instead, there appeared to be mostly google hits for projects #defining _SSIZE_T_DEFINED themselves. If you advise me to go ahead with the wine bug report, I assume they would eventually act on it as a low priority since they claim to want to follow every Microsoft Windows idiosyncrasy that makes a practical difference. Of course
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-09-01 05:45-0700 Alan W. Irwin wrote: On 2011-08-28 14:34-0400 Bill Hoffman wrote: Can you try and build CMake 2.8.4, then 2.8.3 and see what happens? Given many hours of computer time (remember the severe latency issue), yes. I will get to this eventually, but other projects and computer issues are currently delaying it. I needed cmake to build and test ephcom-2.0.2 (see http://timeephem.sourceforge.net/ephcom2.php) on MinGW/MSYS/wine so I just stuck with the distributed cmake binary rather than rebuilding 2.8.5. However, it turned out that wine-1.3.27 had a severe bug that finally expressed itself (everything wine-related ground to a halt) a week later so I switched to wine-1.3.26. That has been rock solid for me ever since which allowed me to finish my Windows testing of ephcom-2.0.2, release it, and finally get back to this topic. I thought wine-1.3.27 might have been to culprit, but it turns out I was just now able to generate the same cmake-2.8.5 build error with MinGW/MSYS/wine-1.3.26. On that same platform, and with the binary version of cmake-2.8.5 (which worked very well for me with ephcom2) I will now attempt builds of cmake-2.8.4 and earlier to see whether the cmake-2.8.5 build error I am getting is a cmake-source code regression for this fixed platform. Meanwhile, could you please consider these further questions just in case the same build error shows up for cmake-2.8.4 and 2.8.3? Does anybody have a clue about where the __LA_DECL and/or __LA_SSIZE_T macros are actually defined? Has anybody here actually attempted to build cmake 2.8.5 using the latest MinGW/MSYS on Microsoft Windows with the MSYS Makefiles generator or is that a completely untested combination up to now? Alan Meanwhile, it would be good to obtain some response to the following questions: If you compare the types of archive_read_data and archive_read_data_into_buffer in archive_read.c versus archive.h, the *.c versions are ssize_t archive_read_data(struct archive *_a, void *buff, size_t s) int archive_read_data_into_buffer(struct archive *a, void *d, ssize_t len) while the *.h versions are __LA_DECL __LA_SSIZE_T archive_read_data(struct archive *, void *, size_t); __LA_DECL int archive_read_data_into_buffer(struct archive *, void *buffer, __LA_SSIZE_T len); So it appears on the MinGW/MSYS/wine platform at least that something is screwed up with the __LA_DECL and/or __LA_SSIZE_T macros. [...]but we should know more about that if somebody can tell me where the above macros are #defined. ??? Also, Has anybody tried that version [latest MinGW/MSYS installer, version 20110802] of MinGW/MSYS on Microsoft Windows to build cmake-2.8.5? It is possible the same build-time error will show up under those conditions. (which would immediately remove wine from the question, and my part in this thread would be done since I have no access to Microsoft Windows.) That automatic installer (available at http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/) literally takes about 5 minutes to download and install all of MinGW/MSYS on wine, and I am sure that it would even be faster on Windows. Is there anybody game to try the build of cmake on Windows using the latest MinGW/MSYS stack you install with the automatic installer ??? 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-08-28 14:34-0400 Bill Hoffman wrote: Can you try and build CMake 2.8.4, then 2.8.3 and see what happens? Given many hours of computer time (remember the severe latency issue), yes. I will get to this eventually, but other projects and computer issues are currently delaying it. Meanwhile, it would be good to obtain some response to the following questions: If you compare the types of archive_read_data and archive_read_data_into_buffer in archive_read.c versus archive.h, the *.c versions are ssize_t archive_read_data(struct archive *_a, void *buff, size_t s) int archive_read_data_into_buffer(struct archive *a, void *d, ssize_t len) while the *.h versions are __LA_DECL __LA_SSIZE_T archive_read_data(struct archive *, void *, size_t); __LA_DECL int archive_read_data_into_buffer(struct archive *, void *buffer, __LA_SSIZE_T len); So it appears on the MinGW/MSYS/wine platform at least that something is screwed up with the __LA_DECL and/or __LA_SSIZE_T macros. [...]but we should know more about that if somebody can tell me where the above macros are #defined. ??? Also, Has anybody tried that version [latest MinGW/MSYS installer, version 20110802] of MinGW/MSYS on Microsoft Windows to build cmake-2.8.5? It is possible the same build-time error will show up under those conditions. (which would immediately remove wine from the question, and my part in this thread would be done since I have no access to Microsoft Windows.) That automatic installer (available at http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/) literally takes about 5 minutes to download and install all of MinGW/MSYS on wine, and I am sure that it would even be faster on Windows. Is there anybody game to try the build of cmake on Windows using the latest MinGW/MSYS stack you install with the automatic installer ??? 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
As an experiment on the MinGW/MSYS/wine platform I tried to build cmake from the bash.exe command line as follows: cmake -G MSYS Makefiles \ -DCMAKE_INSTALL_PREFIX=/z/home/wine/newstart1/cmake/install \ /z/home/software/cmake/cmake-$CMAKE_VERSION cmake.out make make.out where CMAKE_VERSION=2.8.5, the above cmake command is executed with the windows binary version of cmake-2.8.5 you can download from kitware, make is the MSYS version, and I am using the 20110802 version of MinGW/MSYS. That make command errored out part way through with the following messages: [ 35%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read.c.obj z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive_read.c:572:1: error: conflicting types for 'archive_read_data' z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive.h:386:30: note: previous declaration of 'archive_read_data' was here z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive_read.c:651:1: error: conflicting types for 'archive_read_data_into_buffer' z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive.h:411:22: note: previous declaration of 'archive_read_data_into_buffer' was here make[2]: *** [Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read.c.obj] Error 1 make[1]: *** [Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/all] Error 2 make: *** [all] Error 2 If you compare the types of archive_read_data and archive_read_data_into_buffer in archive_read.c versus archive.h, the *.c versions are ssize_t archive_read_data(struct archive *_a, void *buff, size_t s) int archive_read_data_into_buffer(struct archive *a, void *d, ssize_t len) while the *.h versions are __LA_DECL __LA_SSIZE_T archive_read_data(struct archive *, void *, size_t); __LA_DECL int archive_read_data_into_buffer(struct archive *, void *buffer, __LA_SSIZE_T len); So it appears on the MinGW/MSYS/wine platform at least that something is screwed up with the __LA_DECL and/or __LA_SSIZE_T macros. This is a regression on successful cmake builds on MinGW/MSYS/wine that I have done before. However, I am not sure whether it is the new MinGW/MSYS (the new 20110802 version versus 20101030), the new wine (1.3.27 versus 1.3.9), or the new CMake version (2.8.5 versus 2.8.3) that is the culprit here, but we should know more about that if somebody can tell me where the above macros are #defined. Note, I can do some experimentation with MinGW/MSYS/wine, but it should be intelligently focussed rather than brute force because the whole platform has a huge latency (literally a second) for every time cmake, make, or g++ are executed (and probably most other commands as well, although I have found at least one command in that environment [echo done from bash] that is just as fast as on Linux). As we know, cmake itself and well as the Makefile approach it configures tends to split stuff up into many little commands so when you multiply 1 second latency time the number of those commands, all cmake runs and make runs slow down dramatically when compared to the Linux platform. So, for example, I had to wait an hour or so for the above cmake command to finish that configured the cmake build. I have complained in the past about 0.1 second latencies for wine-1.3.9, but the current wine-1.3.27 seems to be ten (!) times worse in this regard. Despite this current latency drawback, the cmake/MinGW/MSYS/wine platform is quite useful for testing for Windows build issues if you don't want to spend a lot of time/effort/money on installing Microsoft Windows on your computer. For example, the above could be a MinGW/MSYS build issue that also occurs for Microsoft Windows for cmake-2.8.5 and the 20110802 version of MinGW/MSYS (the version that is automatically downloaded now by the automated MinGW/MSYS installer you can download using wget http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/mingw-get-inst-20110802/mingw-get-inst-20110802.exe Has anybody tried that version of MinGW/MSYS on Microsoft Windows to build cmake-2.8.5? It is possible the same build-time error will show up under those conditions. 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 __ ___ cmake-developers mailing
Re: [cmake-developers] [CMake 0012374]: DESTDIR is not documented
On 2011-08-01 00:57-0400 Mantis Bug Tracker wrote: == Summary:DESTDIR is not documented http://www.cmake.org/Wiki/CMake_FAQ does document this so would advise immediate closure with that reference to help unclutter bugtracker. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [wishlist BUG?] limit on the length of the CFLAGS environment variable too small?
On 2011-07-31 09:11-0400 Brad King wrote: On 7/30/2011 3:52 AM, Alan W. Irwin wrote: CMakeFiles/cmTryCompileExec.dir/flags.make:6: *** missing separator. Stop. [snip] That missing separator issue makes me think I may be running into some length limit with cmake. The error is coming from the Make tool, not CMake. Try running CMake with --debug-trycompile so it leaves behind the offending flags.make file. Look at the file to see if there is anything funny looking on that line. It looks okay to me, but I am not familiar with the format of that file so I have attached it so you can see for yourself. Also, to help you replicate exactly what I did using the minimal CMakeLists.txt file I posted, here is how I created that CFLAGS: export CFLAGS=$(gcc -c -Q -O0 --help=optimizers \ |grep enabled |sed -e s?\\[enabled\\]? ?g -e s? -f? -fno-?g) CFLAGS=-g $CFLAGS 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); PLplot scientific plotting software package (plplot.org); 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 __# CMAKE generated file: DO NOT EDIT! # Generated by Unix Makefiles Generator, CMake Version 2.8 # compile C with /usr/bin/gcc C_FLAGS =-fno-align-loops -fno-argument-alias -fno-asynchronous-unwind-tables -fno-branch-count-reg -fno-common -fno-dce -fno-dse -fno-early-inlining -fno-gcse-lm -fno-inline-functions-called-once -fno-ivopts -fno-jump-tables -fno-math-errno -fno-move-loop-invariants -fno-peephole -fno-rename-registers -fno-sched-interblock -fno-sched-spec -fno-sched-stalled-insns-dep -fno-signed-zeros -fno-split-ivs-in-unroller -fno-toplevel-reorder -fno-trapping-math -fno-tree-cselim -fno-tree-loop-im -fno-tree-loop-ivcanon -fno-tree-loop-optimize -fno-tree-reassoc -fno-tree-scev-cprop -fno-tree-switch-conversion -fno-tree-vect-loop-version -fno-unit-at-a-time -fno-var-tracking -fno-vect-cost-model -fno-web C_DEFINES = ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0012301]: CMAKE_BUILD_TYPE not set on MinGW
On 2011-06-23 10:22-0600 Clinton Stimpson wrote: FYI, I realized a patch to UseQt4.cmake could fix this qt-plugin/no-build-type problem. See here: http://cmake.org/gitweb?p=cmake.git;a=commit;h=5a2b20 Maybe it'll make it in 2.8.5? Hi Clint: I am replying to your above off-list comment on the list for obvious reasons. I woke up this morning with a very similar idea which I posted to the list before looking at the above off-list note from you. I notice your patch puts BOOLEAN logic protection around the statement I suggested, e.g., +IF(NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE) + SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS QT_NO_DEBUG) +ENDIF() I don't understand why that protection is necessary, but you understand CMake better than I do so I assume you are right. I have high hopes your minimal patch will get into 2.8.5 since it appears to solve many Qt4/MinGW problems. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0012301]: CMAKE_BUILD_TYPE not set on MinGW
On 2011-06-22 17:36-0400 Mantis Bug Tracker wrote: The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12301 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 12301 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-06-22 17:36 EDT Last Modified: 2011-06-22 17:36 EDT == Summary:CMAKE_BUILD_TYPE not set on MinGW Description: CMAKE_BUILD_TYPE is not set when using MinGW, which causes problems with loading Qt plugins unless the user manually sets the CMAKE_BUILD_TYPE. CMAKE_BUILD_TYPE should be preset to debug or release, as it is on most other platforms. Context here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/36994/focus=37032 I have an interest is this bug report and the above thread because of my MinGW/wine tests and experiments with the Qt4 components of PLplot. Also, we currently have a user who is having a devil of a time getting the Qt4 components of PLplot to work reliably on Windows. I have read that thread, but would some MinGW/Windows expert here (such as, ahem, Clint) explain what the real issue is? On Linux, CMAKE_BUILD_TYPE is also not set, but the Qt4 aspects of our PLplot build work fine there. In other words, the Unix Makefiles generator and associated CMake Linux gcc compiler support know exactly what to do if the CMAKE_BUILD_TYPE is not set. (I assume from the documentation that means that the release version of Qt4 is chosen rather than the debug version, but I haven't verified that.) So is the issue really that either/both of MinGW Makefiles or MSYS Makefiles combined with the CMake Windows MinGW compiler support don't know how to correctly handle the case where CMAKE_BUILD_TYPE is not set? Currently, I must say I have sometimes had success with the Qt4 components of PLplot on wine and sometimes not, and I haven't yet pinned down the reason. And we have a PLplot user with very similar Qt4/PLplot reliability issues using MinGW on the Microsoft version of Windows. Because of the information in the above bug report I will try manually setting CMAKE_BUILD_TYPE (I haven't done that before) the next time I build and test PLplot on wine, and I have suggested our user do the same on Microsoft Windows, in the hope it will make the Qt4 components of PLplot more reliable on those platforms. Clint, I had planned to restart MinGW/MSYS/Wine and MinGW/Wine testing of PLplot builds in the next several weeks, but I could start those tests earlier if it would clarify some of the issues you discovered for the case when CMAKE_BUILD_TYPE was not set manually. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0012280]: FindSWIG won't find swig 1.3
On 2011-06-15 16:19-0400 Mantis Bug Tracker wrote: The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12280 == Reported By:Julien Malik Assigned To: == Project:CMake Issue ID: 12280 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-06-15 16:19 EDT Last Modified: 2011-06-15 16:19 EDT == Summary:FindSWIG won't find swig 1.3 Description: I have swig 1.3 installed, but not 2.0 CMake won't find swig automatically. If I install 2.0, swig is found correctly. The attached patch fixes it. Seems like find_program is not called with conventions from the documentation. Steps to Reproduce: project(TestFindSWIG) cmake_minimum_required(VERSION 2.8) find_package(SWIG) Brad has accepted this patch and closed the bug. However, I am interested because PLplot uses swig-1.3 with no user reports of problems (has done for years). I personally have never seen swig finding problems for Linux and also a MinGW/MSYS/wine platform. Furthermore, I cannot reproduce the bug even with the simple test example above for my platform (Debian stable with CMake-2.8.4 that I built myself, and swig version 1.3.40-3). On the other hand, the patch does look correct to me. So, Brad, how in the world does find_package(SWIG) work at all for both my Linux and wine platforms? Or to put it another way, for what platforms (with swig-1.3) will this bug be triggered (until the fix goes into a release)? 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] I want to use CMake in Solaris10 x86
On 2011-06-14 10:37+0800 feng.zhou wrote: Hi I cannot find insall packet in download list,only Solaris spack packet can be found.How to solve this question ,thanks Try building cmake from the source code using the bootstrap method (i.e. running the bootstrap script in the top-level source tree directory following the directions in Readme.txt in that directory). 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake 2.8.5-rc1 ready for testing!
On 2011-05-25 14:25-0400 David Cole wrote: I am happy to announce that CMake 2.8.5 has entered the release candidate stage! You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D Hi Dave: Has bug 9220 been fixed for this release candidate? http://public.kitware.com/Bug/view.php?id=9220 says it is targeted for 2.8.5, but there doesn't seem to be any mention of it in the 2.8.5-rc1 Changelog you posted. I would really like to see this bug properly fixed for 2.8.5 since the workaround you suggested long ago of invoking a cmake session from within your principal cmake session to independently test language support has limitations. For example, it is difficult to propagate user-specified compilers or compiler flags from the principal cmake session to the test cmake session because there are so many different ways for the user to specify compiler or compiler flags. Once there is a proper fix for 9220, I would be happy to help test it. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake to GMake issues
On 2011-01-24 17:02- Chris Lawrence wrote: Hi, I've recently been looking into using CMake with one of my projects at work. I've recently run into a problem where the Makefile, CMake generates will not run on my build system unless I install the cmake libraries. Just to clarify, my development machine (where CMake is installed) and my build machine are separate. My project requires the use of the generated makefile, without the dependence of having cmake installed on that machine. Is there any flags available for CMake, to generate a gmake file that can be run independently from the cmake libraries? To the CMake developers here: should the answer be in the FAQ? My quick check could not find it there. To Chris: This subject is probably more appropriate for the cm...@cmake.org list where the question has been answered a number of times already, but I will attempt to answer it here. In short, the answer is no. If you run make VERBOSE=1 you will see cmake is invoked for at least progress reports and dependency analysis. Also, if you want your build to be cross-platform at all, as a build system designer you will be using the cmake -E commands to do cross-platform commands such as the following: Usage: cmake -E [command] [arguments ...] Available commands: chdir dir cmd [args]... - run command in a given directory rename oldname newname- rename a file or directory (on one volume) copy file destination - copy file to destination (either file or directory) copy_if_different in-file out-file - copy file if input has changed copy_directory source destination - copy directory 'source' content to directory 'destination' compare_files file1 file2 - check if file1 is same as file2 echo [string]... - displays arguments as text echo_append [string]... - displays arguments as text but no new line environment - display the current environment make_directory dir- create a directory md5sum file1 [...]- compute md5sum of files remove_directory dir - remove a directory and its contents remove [-f] file1 file2 ... - remove the file(s), use -f to force it tar [cxt][vfz][cvfj] file.tar file/dir1 file/dir2 ... - create a tar archive time command [args] ... - run command and return elapsed time touch file- touch a file. touch_nocreate file - touch a file but do not create it. build build_dir - build the project in build_dir. create_symlink old new- create a symbolic link new - old So even if you could get rid of the progress reports and dependency analysis, then you severely limit the cross-platform usefulness of your package by not being able to use these commands at make time. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using cmake pkg-config-like in non-cmake builds
On 2010-11-22 21:55+0100 Alexander Neundorf wrote: Hi, there can be the case that a package which has been built with cmake, should be used in a project which doesn't use cmake. There is a feature request that cmake should help with generating pkg-config pc-files: http://public.kitware.com/Bug/view.php?id=11446 I don't like that idea, because a) this means duplicating information, and b) doing that in a less powerful format. I have a slightly different idea: instead of having cmake generate pc-files, modify/extend cmake so that it can be used similar to pkg-config by projects which don't use cmake as their buildsystem. I attached a first very quick try to that bug report. It's a small cmake script which can be executed by cmake with -P, and which basically contains one find_package() call and prints the results, so they can be fed into a compiler invocation in a makefile. It already somewhat works: $ cmake -DMODE=COMPILE -DCOMPILER_ID=GNU -DPACKAGE=PNG -P cmake-config.cmake -I/usr/include -I/usr/include $ cmake -DMODE=LINK -DCOMPILER_ID=GNU -DPACKAGE=PNG -P cmake-config.cmake /usr/lib/libpng.so /usr/lib/libz.so Do you think this makes sense ? Hi Alex: How did you collect that compiler flag information? As far as I know the command install(EXPORT ) only writes out information about the link flags but not the compile flags associated with a given library target. If your method of obtaining compile flag information is general enough, then it should be straightforward to modifiy that install signature to write out the compile flags as well, and that would be a huge win. For example, PLplot currently uses install(EXPORT ) to collect link flag information for all its libraries for the use of external projects. And we use that information for an external CMake-based build system we have implemented to build and exhaustively test our installed examples. That build system would be a lot less cumbersome if we had access to compile flags for each of our libraries through the EXPORTed cmake file. Thus, in answer to your primary question, I think the cmake file written out by install(EXPORT ...) is the right format to use for compile flag and linker flag information if the above suggested enhancement to install(EXPORT...) was made. Once compile and link flag data were collected in a format like that, it should be a simple matter to parse those data into any other form that developers might like including dumping those data directly to the command line as in your proof of concept 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add support for IAR compilers
On 2010-10-17 16:17+0200 Alexander Neundorf wrote: Hi, basically since January this year I am busy with adding support for the IAR compilers to cmake: http://public.kitware.com/Bug/view.php?id=10176 Main problem is that they run only under Windows, I don't have Windows, and I also already tried to get them installed on a ReactOS QEmu image, but didn't succeed, in the end some things didn't work. Hi Alex: I also don't have access to Windows but need to test software (PLplot and FreeEOS in my case) for that platform. I have used Wine (the free Windows workalike accessible under Linux) for this testing purpose, and you might want to consider this platform for your Windows testing needs as well. Of course, Wine is not a perfect Windows workalike, but those developers try very hard to implement that goal, and keep getting better and better at realizing that goal. Thus, if your Wine testing succeeds, there is a good chance the software you are testing will work on proprietary Windows as well. According to http://en.wikipedia.org/wiki/ReactOS, ReactOS does use some parts of Wine but cannot use it all. It is also unclear to me how well ReactOS keeps up with the latest Wine (Wine puts out a new development release every two weeks) or whether some of the issues you encountered were due to some non-Wine ReactOS issue. (ReactOS is a standalone OS while the OS part is taken care of by Linux for Wine so should be completely reliable in that case.) Under Wine, and using a downloaded Windows binary version of the MinGW set of compilers, I have used a downloaded Windows binary of CMake to build CMake itself, and then used that Wine-built version of CMake to build and (successfully) test PLplot. These preliminary Wine/CMake/MinGW results look quite promising so you might find that Wine/CMake/IAR also works well. Anyhow, it is worth a try since it is a good feeling to have Windows-workalike platform testing under your own hands to complement proprietary Windows platform testing done by others. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] CMake code style
On 2010-09-20 16:20-0400 Bill Hoffman wrote:
BTW, this type of code is not allowed in CMake:
if (fi!=files.begin()) os ;;
Needs to be:
if((fi!=files.begin())
{
os ;;
}
If you want a consistent coding style in CMake, I suggest you give
uncrustify a look. It is extremely powerful and configurable, and we
are quite pleased with the results it gives in the PLplot case.
Let's face it, with a variety of humans involved with a code base some
inconsistent coding style is constantly creeping in. To stop that you
need (1) some sort of style czar or (2) some semi-automatic script
that does the job which one core developer runs by hand aperiodically
to bring all code into conformance with a uniform style. I feel that
(2) is the better choice since it gives consistent results and better
feelings amongst developers since it is easier to come to consensus on
uncrustify options you are going to use then argue over styling of
individual files.
I have put together a shell script that is based on uncrustify and
which has options for listing all files that don't conform to the
ideal standard, showing differences between the ideal style and
actuality for those files (both in diff -auw format and diff -au
format), and a final option that fixes all those differences once you
are satisfied you like the changes that the diff options show. You
are welcome to modify the script any way you like for your needs. See
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/uncrustify.cfg?view=log
and
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/scripts/style_source.sh?view=log.
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); PLplot scientific plotting software
package (plplot.org); 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
__
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] fphsa capitalization
On 2010-08-14 16:25+0200 Eric Noulard wrote: I know this may seems overkill, because we are only speaking about ExactCase vs UPPERCASE, but if we take the backward compatibilty seriously and want to progress towards to ExactCMake, may be it's a possible idea. Now I think I just unveil myself a CMake pandora box, the whatever case getter I propose is not too far away from the MACRO(WhatEvERcase) or FUNCTION(WHATeverCase) behavior. I let you run the attached cmake script and tell me if you knew this flexible CMake command naming was true for MACRO and FUNCTION too ? This is genuine consistent but why doing this on macro and not on vars? As a CMake-based build-system implementer for various software packages, I was well aware of and do like the convenience of case-insensitive use of commands, macros, and functions. However, variables are a different story and _in general_ there you want to maximize the possibilities for the largest possible namespace so case insensitivity would be a bad idea for variables _in general_. However, for the specific case of the variables set by find modules, the present mess is unacceptable, and CMake should move to an enforced consistent naming convention as soon as possible. I will let others more competent than me in CMake internals comment on the technical merits of Eric's proposals, but I think the idea of removing a lot of the pain of converting to a consistent naming convention for the variables set by find modules using technical means is a good one. Assuming Eric's or similar proposals are implemented to remove that conversion pain, I agree with Brad that since we already must use exact case for referring to the find module name with the find_package command, it makes a lot of sense to use that same exact-case name as a prefix for the variables set by that find module. My hope is that with the conversion pain removed, Alex would be willing to go along with the exact case naming convention so that solving the current naming convention mess is not delayed too much longer. 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); PLplot scientific plotting software package (plplot.org); 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
