From: Chuck A. <chu...@ki...> - 2010-09-10 17:34:30
|
Is there any hard requirement to keep the cmake minimum at 2.4.5 instead of moving it to 2.6? Chuck Atkins R&D Engineer, Kitware, Inc. (518) 371-3971 x603 chu...@ki... -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos |
From: Peter V. <pet...@ya...> - 2010-09-11 09:58:18
|
CMake 2.6 has been out for more than 2 years now, and 2.8 is out, so I also don't see a reason why we should stick at 2.4.5. On the other hand, as long as vxl does not use any new 2.6 features, it's maybe nice for CMake 2.4 users to know that they are still safe. Two questions: - Are there any "current" Linux distributions which still contain 2.4? - Are there any 2.6 new features which vxl would benefit from? -- Peter. |
From: Chuck A. <chu...@ki...> - 2010-10-29 14:28:46
|
I posted this a while ago but I haven't really been able to think of too many highly desired features that would motivate this upgrade. Upon furthor though, I have come up with a few that I think are fairly motivating: 1. New syntax available for add_test employing the use of generator expressions . Right now most of the tests are specified as: add_executable( MyTestDriver ${TEST_SOURCES} ) add_test( MyTestName ${EXECUTABLE_OUTPUT_PATH}/MyTestDriver --args --to --test ) The problem is that the EXECUTABLE_OUTPUT_PATH is the default output location for all executables but there's no requirement that the executable is actually there. There's just an asssumption that the targewt will go into the default location. Target properties could have been set that will place the executable somewhere else entirely. The new syntax for add_test that can accommodate this uses "generator expressions". The generator expressions allow cmake to resolve the actual output location of a target: add_executable( MyTestDriver ${TEST_SOURCES} ) add_test( NAME MyTestName COMMAND $<TARGET_FILE:MyTestDriver> --args --to --test) $<TARGET_FILE:MyTestDriver> will be resolved to the full path of the output executable. This is known by cmake at build system generation time. More can be read here: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_test 2. The deprecation of EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH in favor of a new set of output locations: ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and RUNTIME_OUTPUT_DIRECTORY target properties. More details can be found on the CMake 2.6 or 2.8 docs page but essentially this allows the the buuld system ti distinguish between runtime components and link time components. So on windows, for instance, for a shared library, the DLL get placed in the RUNTIME_OUTPUT_DIRECTORY and the import library would be placed in the ARCHIVE_OUTPUT_DIRECTORY instead of them both getting placed in the library destination. Currently VXL doesn't support shared libraries on Windows because it's missing all of the declspec(_dllexport) decorations but if there's ever a though of getting there then having this seperation is really nice to have. 3. Amitha just raised another argument in respose to a different thread: "This macro is usually only defined for gcc, which allows const float initializers as an extension even on C++98. There is a try-compile during configure time that tries to figure out if the compiler supports it or not. However, the test only looks for a successful exit from the compiler (i.e., no errors), and so the test would not catch the warning. Newer CMake versions have a way of doing try-compiles that parse the output of the test case. (I'm not sure exactly which version.) If we were willing to update the required version of CMake, we could update the try-compile to fail if there are warnings or errors." Thoughts? Suggestions? Comments? Objections? - Chuck -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos On Sat, Sep 11, 2010 at 5:58 AM, Peter Vanroose <pet...@ya...>wrote: > CMake 2.6 has been out for more than 2 years now, and 2.8 is out, so I also > don't see a reason why we should stick at 2.4.5. > > On the other hand, as long as vxl does not use any new 2.6 features, it's > maybe nice for CMake 2.4 users to know that they are still safe. > > Two questions: > - Are there any "current" Linux distributions which still contain 2.4? > - Are there any 2.6 new features which vxl would benefit from? > > -- Peter. > > > > > > > > > |
From: Peter V. <pet...@ya...> - 2010-10-29 21:05:35
|
Thanks! Those are indeed good reasons to go for CMake 2.6 (and for the proposed changes). -- Peter. --- On 2010-10-29 Chuck Atkins <chu...@ki...> wrote: I posted this a while ago but I haven't really been able to think of too many highly desired features that would motivate this upgrade. Upon furthor though, I have come up with a few that I think are fairly motivating: 1. New syntax available for add_test employing the use of generator expressions . Right now most of the tests are specified as: add_executable( MyTestDriver ${TEST_SOURCES} ) add_test( MyTestName ${EXECUTABLE_OUTPUT_PATH}/MyTestDriver --args --to --test ) The problem is that the EXECUTABLE_OUTPUT_PATH is the default output location for all executables but there's no requirement that the executable is actually there. There's just an asssumption that the targewt will go into the default location. Target properties could have been set that will place the executable somewhere else entirely. The new syntax for add_test that can accommodate this uses "generator expressions". The generator expressions allow cmake to resolve the actual output location of a target: add_executable( MyTestDriver ${TEST_SOURCES} ) add_test( NAME MyTestName COMMAND $<TARGET_FILE:MyTestDriver> --args --to --test) $<TARGET_FILE:MyTestDriver> will be resolved to the full path of the output executable. This is known by cmake at build system generation time. More can be read here: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_test 2. The deprecation of EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH in favor of a new set of output locations: ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and RUNTIME_OUTPUT_DIRECTORY target properties. More details can be found on the CMake 2.6 or 2.8 docs page but essentially this allows the the buuld system ti distinguish between runtime components and link time components. So on windows, for instance, for a shared library, the DLL get placed in the RUNTIME_OUTPUT_DIRECTORY and the import library would be placed in the ARCHIVE_OUTPUT_DIRECTORY instead of them both getting placed in the library destination. Currently VXL doesn't support shared libraries on Windows because it's missing all of the declspec(_dllexport) decorations but if there's ever a though of getting there then having this seperation is really nice to have. 3. Amitha just raised another argument in respose to a different thread: "This macro is usually only defined for gcc, which allows const float initializers as an extension even on C++98. There is a try-compile during configure time that tries to figure out if the compiler supports it or not. However, the test only looks for a successful exit from the compiler (i.e., no errors), and so the test would not catch the warning. Newer CMake versions have a way of doing try-compiles that parse the output of the test case. (I'm not sure exactly which version.) If we were willing to update the required version of CMake, we could update the try-compile to fail if there are warnings or errors." Thoughts? Suggestions? Comments? Objections? - Chuck -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos On Sat, Sep 11, 2010 at 5:58 AM, Peter Vanroose <pet...@ya...> wrote: CMake 2.6 has been out for more than 2 years now, and 2.8 is out, so I also don't see a reason why we should stick at 2.4.5. On the other hand, as long as vxl does not use any new 2.6 features, it's maybe nice for CMake 2.4 users to know that they are still safe. Two questions: - Are there any "current" Linux distributions which still contain 2.4? - Are there any 2.6 new features which vxl would benefit from? -- Peter. |
From: Joseph M. <mu...@le...> - 2010-10-29 21:40:24
|
At Brown, I think most people are already at CMake 2.8, so 2.6 should be fine. Joe From: Peter Vanroose [mailto:pet...@ya...] Sent: Friday, October 29, 2010 5:05 PM To: Chuck Atkins Cc: vxl maintainers Subject: Re: [Vxl-maintainers] CMake Minimum Thanks! Those are indeed good reasons to go for CMake 2.6 (and for the proposed changes). -- Peter. --- On 2010-10-29 Chuck Atkins <chu...@ki...> wrote: I posted this a while ago but I haven't really been able to think of too many highly desired features that would motivate this upgrade. Upon furthor though, I have come up with a few that I think are fairly motivating: 1. New syntax available for add_test employing the use of generator expressions . Right now most of the tests are specified as: add_executable( MyTestDriver ${TEST_SOURCES} ) add_test( MyTestName ${EXECUTABLE_OUTPUT_PATH}/MyTestDriver --args --to --test ) The problem is that the EXECUTABLE_OUTPUT_PATH is the default output location for all executables but there's no requirement that the executable is actually there. There's just an asssumption that the targewt will go into the default location. Target properties could have been set that will place the executable somewhere else entirely. The new syntax for add_test that can accommodate this uses "generator expressions". The generator expressions allow cmake to resolve the actual output location of a target: add_executable( MyTestDriver ${TEST_SOURCES} ) add_test( NAME MyTestName COMMAND $<TARGET_FILE:MyTestDriver> --args --to --test) $<TARGET_FILE:MyTestDriver> will be resolved to the full path of the output executable. This is known by cmake at build system generation time. More can be read here: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_test 2. The deprecation of EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH in favor of a new set of output locations: ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and RUNTIME_OUTPUT_DIRECTORY target properties. More details can be found on the CMake 2.6 or 2.8 docs page but essentially this allows the the buuld system ti distinguish between runtime components and link time components. So on windows, for instance, for a shared library, the DLL get placed in the RUNTIME_OUTPUT_DIRECTORY and the import library would be placed in the ARCHIVE_OUTPUT_DIRECTORY instead of them both getting placed in the library destination. Currently VXL doesn't support shared libraries on Windows because it's missing all of the declspec(_dllexport) decorations but if there's ever a though of getting there then having this seperation is really nice to have. 3. Amitha just raised another argument in respose to a different thread: "This macro is usually only defined for gcc, which allows const float initializers as an extension even on C++98. There is a try-compile during configure time that tries to figure out if the compiler supports it or not. However, the test only looks for a successful exit from the compiler (i.e., no errors), and so the test would not catch the warning. Newer CMake versions have a way of doing try-compiles that parse the output of the test case. (I'm not sure exactly which version.) If we were willing to update the required version of CMake, we could update the try-compile to fail if there are warnings or errors." Thoughts? Suggestions? Comments? Objections? - Chuck -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos On Sat, Sep 11, 2010 at 5:58 AM, Peter Vanroose <pet...@ya...> wrote: CMake 2.6 has been out for more than 2 years now, and 2.8 is out, so I also don't see a reason why we should stick at 2.4.5. On the other hand, as long as vxl does not use any new 2.6 features, it's maybe nice for CMake 2.4 users to know that they are still safe. Two questions: - Are there any "current" Linux distributions which still contain 2.4? - Are there any 2.6 new features which vxl would benefit from? -- Peter. |
From: Gehua Y. <yan...@gm...> - 2010-10-29 21:17:08
|
Chuck, I am personally in favor of raising the minimum CMake version and I like all of your motivations. Do you think it is enough to cover the three motivations with minimum CMake version of 2.6.0? Or 2.8.0 is needed? I personally do not care about either, but just want to make it clear for the discussion. Regards, Gehua Yang On Fri, Oct 29, 2010 at 10:28 AM, Chuck Atkins <chu...@ki...> wrote: > > I posted this a while ago but I haven't really been able to think of too many highly desired features that would motivate this upgrade. Upon furthor though, I have come up with a few that I think are fairly motivating: > > 1. New syntax available for add_test employing the use of generator expressions . Right now most of the tests are specified as: > > add_executable( MyTestDriver ${TEST_SOURCES} ) > add_test( MyTestName ${EXECUTABLE_OUTPUT_PATH}/MyTestDriver --args --to --test ) > > The problem is that the EXECUTABLE_OUTPUT_PATH is the default output location for all executables but there's no requirement that the executable is actually there. There's just an asssumption that the targewt will go into the default location. Target properties could have been set that will place the executable somewhere else entirely. The new syntax for add_test that can accommodate this uses "generator expressions". The generator expressions allow cmake to resolve the actual output location of a target: > > add_executable( MyTestDriver ${TEST_SOURCES} ) > add_test( NAME MyTestName > COMMAND $<TARGET_FILE:MyTestDriver> --args --to --test) > > $<TARGET_FILE:MyTestDriver> will be resolved to the full path of the output executable. This is known by cmake at build system generation time. More can be read here: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_test > > 2. The deprecation of EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH in favor of a new set of output locations: ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY, and RUNTIME_OUTPUT_DIRECTORY target properties. More details can be found on the CMake 2.6 or 2.8 docs page but essentially this allows the the buuld system ti distinguish between runtime components and link time components. So on windows, for instance, for a shared library, the DLL get placed in the RUNTIME_OUTPUT_DIRECTORY and the import library would be placed in the ARCHIVE_OUTPUT_DIRECTORY instead of them both getting placed in the library destination. Currently VXL doesn't support shared libraries on Windows because it's missing all of the declspec(_dllexport) decorations but if there's ever a though of getting there then having this seperation is really nice to have. > > 3. Amitha just raised another argument in respose to a different thread: > > "This macro is usually only defined for gcc, which allows const float > initializers as an extension even on C++98. There is a try-compile > during configure time that tries to figure out if the compiler supports > it or not. However, the test only looks for a successful exit from the > compiler (i.e., no errors), and so the test would not catch the warning. > > Newer CMake versions have a way of doing try-compiles that parse the > output of the test case. (I'm not sure exactly which version.) If we > were willing to update the required version of CMake, we could update > the try-compile to fail if there are warnings or errors." > > > Thoughts? Suggestions? Comments? Objections? > > - Chuck > > -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos > > > On Sat, Sep 11, 2010 at 5:58 AM, Peter Vanroose <pet...@ya...> wrote: >> >> CMake 2.6 has been out for more than 2 years now, and 2.8 is out, so I also don't see a reason why we should stick at 2.4.5. >> >> On the other hand, as long as vxl does not use any new 2.6 features, it's maybe nice for CMake 2.4 users to know that they are still safe. >> >> Two questions: >> - Are there any "current" Linux distributions which still contain 2.4? >> - Are there any 2.6 new features which vxl would benefit from? >> >> -- Peter. >> >> >> >> >> >> >> >> > > > ------------------------------------------------------------------------------ > Nokia and AT&T present the 2010 Calling All Innovators-North America contest > Create new apps & games for the Nokia N8 for consumers in U.S. and Canada > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store > http://p.sf.net/sfu/nokia-dev2dev > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Chuck A. <chu...@ki...> - 2010-10-29 21:51:39
|
The target generator expressions (personally my favorite "killer feature") are new to 2.8 so those won't be available in 2.6. 2.8 also brings with it git support but I dont see that as much of an issue unless there's any plans to migrate from svn to git and we should leave that topic for an entirely seperate thread anyways. There definitely seems to be a case for going to 2.6 but is there a good reason to not go to 2.8? Perhaps it would be a question to also ask for feedback on the vxl-users list as well. Chuck Atkins R&D Engineer, Kitware, Inc. (518) 371-3971 x603 chu...@ki... -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos On Fri, Oct 29, 2010 at 5:17 PM, Gehua Yang <yan...@gm...> wrote: > Chuck, > > I am personally in favor of raising the minimum CMake version and I > like all of your motivations. > > Do you think it is enough to cover the three motivations with minimum > CMake version of 2.6.0? Or 2.8.0 is needed? I personally do not > care about either, but just want to make it clear for the discussion. > > Regards, > Gehua Yang > > > On Fri, Oct 29, 2010 at 10:28 AM, Chuck Atkins <chu...@ki...> > wrote: > > > > I posted this a while ago but I haven't really been able to think of too > many highly desired features that would motivate this upgrade. Upon furthor > though, I have come up with a few that I think are fairly motivating: > > > > 1. New syntax available for add_test employing the use of generator > expressions . Right now most of the tests are specified as: > > > > add_executable( MyTestDriver ${TEST_SOURCES} ) > > add_test( MyTestName ${EXECUTABLE_OUTPUT_PATH}/MyTestDriver --args --to > --test ) > > > > The problem is that the EXECUTABLE_OUTPUT_PATH is the default output > location for all executables but there's no requirement that the executable > is actually there. There's just an asssumption that the targewt will go > into the default location. Target properties could have been set that will > place the executable somewhere else entirely. The new syntax for add_test > that can accommodate this uses "generator expressions". The generator > expressions allow cmake to resolve the actual output location of a target: > > > > add_executable( MyTestDriver ${TEST_SOURCES} ) > > add_test( NAME MyTestName > > COMMAND $<TARGET_FILE:MyTestDriver> --args --to --test) > > > > $<TARGET_FILE:MyTestDriver> will be resolved to the full path of the > output executable. This is known by cmake at build system generation time. > More can be read here: > http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_test > > > > 2. The deprecation of EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH in > favor of a new set of output locations: ARCHIVE_OUTPUT_DIRECTORY, > LIBRARY_OUTPUT_DIRECTORY, and RUNTIME_OUTPUT_DIRECTORY target properties. > More details can be found on the CMake 2.6 or 2.8 docs page but essentially > this allows the the buuld system ti distinguish between runtime components > and link time components. So on windows, for instance, for a shared > library, the DLL get placed in the RUNTIME_OUTPUT_DIRECTORY and the import > library would be placed in the ARCHIVE_OUTPUT_DIRECTORY instead of them both > getting placed in the library destination. Currently VXL doesn't support > shared libraries on Windows because it's missing all of the > declspec(_dllexport) decorations but if there's ever a though of getting > there then having this seperation is really nice to have. > > > > 3. Amitha just raised another argument in respose to a different > thread: > > > > "This macro is usually only defined for gcc, which allows const float > > initializers as an extension even on C++98. There is a try-compile > > during configure time that tries to figure out if the compiler supports > > it or not. However, the test only looks for a successful exit from the > > compiler (i.e., no errors), and so the test would not catch the warning. > > > > Newer CMake versions have a way of doing try-compiles that parse the > > output of the test case. (I'm not sure exactly which version.) If we > > were willing to update the required version of CMake, we could update > > the try-compile to fail if there are warnings or errors." > > > > > > Thoughts? Suggestions? Comments? Objections? > > > > - Chuck > > > > -- "Mathematicians are tools for turning coffee grounds into formulas.", > Paul Erdos > > > > > > On Sat, Sep 11, 2010 at 5:58 AM, Peter Vanroose < > pet...@ya...> wrote: > >> > >> CMake 2.6 has been out for more than 2 years now, and 2.8 is out, so I > also don't see a reason why we should stick at 2.4.5. > >> > >> On the other hand, as long as vxl does not use any new 2.6 features, > it's maybe nice for CMake 2.4 users to know that they are still safe. > >> > >> Two questions: > >> - Are there any "current" Linux distributions which still contain 2.4? > >> - Are there any 2.6 new features which vxl would benefit from? > >> > >> -- Peter. > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > > ------------------------------------------------------------------------------ > > Nokia and AT&T present the 2010 Calling All Innovators-North America > contest > > Create new apps & games for the Nokia N8 for consumers in U.S. and > Canada > > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in > marketing > > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store > > http://p.sf.net/sfu/nokia-dev2dev > > _______________________________________________ > > Vxl-maintainers mailing list > > Vxl...@li... > > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > |