Re: [cmake-developers] User vs CMake include mismatch handling
On Wednesday 15 December 2010, Brad King wrote: > On 12/15/2010 05:31 PM, Brad King wrote: > > + e << "CMake builtin module\n" > > +<< " " << includer << "\n" > > +<< "is including a module from the CMAKE_MODULE_PATH\n" > > +<< " " << moduleInCMakeModulePath << "\n" > > +<< "which shadows expected builtin module\n" > > +<< " " << moduleInCMakeRoot << "\n" > > +<< "This may cause CMake or build errors later.\n" > > BTW, when I merge the branch to master for testing the FindPackageTest > does not actually do anything due to use of ${CMAKE_CURRENT_LIST_DIR} > in FindZLIB. > > -Brad Yes, the plan is to remove the uses of ${CMAKE_CURRENT_LIST_DIR} at this point again. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011617]: Add warning to file(GLOB help text
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11617 == Reported By:Ryan Pavlik Assigned To: == Project:CMake Issue ID: 11617 Category: CMake Reproducibility:N/A Severity: text Priority: normal Status: new == Date Submitted: 2010-12-16 14:15 EST Last Modified: 2010-12-16 14:15 EST == Summary:Add warning to file(GLOB help text Description: >From my observations on the mailing list, the first instinct of a lot of users is to use file(GLOB to assemble lists of sources - not to do so is certainly one of the more frequent repeated responses. It seems that it would be prudent to add a warning to the help text stating that it shouldn't be used for this purpose and a brief explanation why (CMake can't automatically tell when you have added/removed a file in the directory). == Issue History Date ModifiedUsername FieldChange == 2010-12-16 14:15 Ryan PavlikNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011616]: CMake crashes when clicking Generate with this minimal CMakeLists.txt
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11616 == Reported By:Ryan Pavlik Assigned To: == Project:CMake Issue ID: 11616 Category: CMake Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 2010-12-16 14:13 EST Last Modified: 2010-12-16 14:13 EST == Summary:CMake crashes when clicking Generate with this minimal CMakeLists.txt Description: Crashes when the project type is set to NONE. This occurs in 2.8.2 and 2.8.3. Steps to Reproduce: Put these two lines in a CMakeLists.txt and configure/generate: cmake_minimum_required(VERSION 2.8) project(bug-testcase NONE) Notice that it crashes. Remove NONE, and try again. It doesn't crash. == Issue History Date ModifiedUsername FieldChange == 2010-12-16 14:13 Ryan PavlikNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011615]: CHECK_C_COMPILER_FLAG Problem, simple fix.
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=11615 == Reported By:Campbell Barton Assigned To: == Project:CMake Issue ID: 11615 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2010-12-16 12:37 EST Last Modified: 2010-12-16 12:37 EST == Summary:CHECK_C_COMPILER_FLAG Problem, simple fix. Description: This fails with GCC because the macro compiles "int main() { return 0;}" Simple fix is to change it to "int main(void) { return 0;}" in CheckCCompilerFlag.cmake Example: include(CheckCCompilerFlag) CHECK_C_COMPILER_FLAG(-Werror=strict-prototypes MYRESULT == Issue History Date ModifiedUsername FieldChange == 2010-12-16 12:37 Campbell BartonNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0011209]: Support generator expression everywhere they make sense
Oh, sweet, didn't know there was a bug open for this. +1! Can't wait to get my hands dirty with 2.8.4 -Johan On Thu, Dec 16, 2010 at 8:46 AM, Michael Wild wrote: > Thanks Brad, that's fantastic! Kind of a premature Christmas gift ;-) > > Michael > > On 12/15/2010 09:43 PM, Mantis Bug Tracker wrote: > > > > The following issue has been RESOLVED. > > == > > http://public.kitware.com/Bug/view.php?id=11209 > > == > > Reported By:Michael Wild > > Assigned To:Brad King > > == > > Project:CMake > > Issue ID: 11209 > > Category: CMake > > Reproducibility:N/A > > Severity: feature > > Priority: normal > > Status: resolved > > Resolution: fixed > > Fixed in Version: > > == > > Date Submitted: 2010-09-07 02:10 EDT > > Last Modified: 2010-12-15 15:43 EST > > == > > Summary:Support generator expression everywhere they > make > > sense > > Description: > > It would be very convenient if CMake supported the generator expressions > > available in the ADD_TEST command in all user-definable commands that run > at > > build time. ADD_CUSTOM_COMMAND and ADD_CUSTOM_TARGET spring to mind. > > == > > Relationships ID Summary > > -- > > related to 0009974 CMake should support custom commands th... > > == > > > > -- > > (0024189) Brad King (developer) - 2010-12-15 15:36 > > http://public.kitware.com/Bug/view.php?id=11209#c24189 > > -- > > I've wanted to do this feature for a long time. I finally got my chance > this > > month and have been working on it for a couple weeks. > > > > The main commit is > > > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0cdb600 > > > > but a lot of refactoring and cleanup was needed to get to that point. > The full > > commit range produced by this effort was > > > > git log --graph afc89064..f0cdb600 > > > > -- > > (0024190) Brad King (developer) - 2010-12-15 15:42 > > http://public.kitware.com/Bug/view.php?id=11209#c24190 > > -- > > Commit f0cdb600 adds support for generator expressions in > add_custom_command and > > add_custom target. They already work in add_test. > > > > The only other place I can think that non-C++ (pure CMake) code can > define > > commands is the Makefile generator rule variables like > > CMAKE__COMPILE_OBJECT. These are very specific to one generator > though. > > Actually the placeholder syntax they use, such as "", was one of > the > > reasons we chose $<> syntax for generator expressions in the first place. > We > > anticipated adding them elsewhere beyond add_test. However, since rule > > variables are already expanded with per-configuration substitution I > don't > > currently see a use case for generator expressions there. Although it > may help > > cleanup our builtin rule variables we would always have to support the > old-style > > placeholders so I don't want to add extra code until we have a good > reason. > > > > Issue History > > Date ModifiedUsername FieldChange > > == > > 2010-09-07 02:10 Michael Wild New Issue > > 2010-12-15 12:02 David Cole Assigned To => Brad King > > 2010-12-15 12:02 David Cole Status new => assigned > > 2010-12-15 14:28 Brad King Relationship added related to > 0009974 > > 2010-12-15 15:36 Brad King Note Added: 0024189 > > 2010-12-15 15:42 Brad King Note Added: 0024190 > > 2010-12-15 15:43 Brad King Status assigned => > resolved > > 2010-12-15 15:43 Brad King Resolution open => fixed > > == > > > > ___ > cmake-developers mailing list > cmake-developers@cmake.org > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers > ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin