Re: [cmake-developers] Ninja windows
On 3/7/2012 5:24 PM, David Cole wrote: That might be fixed just now (perhaps) by stuff that I merged into 'next' this afternoon. Try with the very latest next of CMake. (One of the commits from Peter K. had not yet been merged into next and it dealt with directory creation...) That fixed it. I pulled from next again and it created the directories. -Bill -- 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] How to handle package Config.cmake files with dependencies ?
On Mar 7, 2012, at 5:39 PM, Alexander Neundorf wrote: > On Wednesday 07 March 2012, Brad King wrote: >> On 3/7/2012 9:49 AM, Michael Hertling wrote: >>> been found, but in module mode, AFAIK, it's set to Foo_DIR-NOTFOUND >>> even if a find module has succeeded >> >> The Foo_DIR variable is not set or added to the cache at all if >> a FindFoo module is loaded regardless of whether it succeeds. >> It is only if no FindFoo module is found that Foo_DIR appears. >> >>> my question is still: How can I figure out in a reliable manner >>> that FIND_PACKAGE(Foo ...) has found neither FindFoo.cmake nor >>> FooConfig.cmake? >> >> The call site should *know* whether it is intending to use a >> Find module or look for a package config file based on whether >> the the author adds a Find module to CMAKE_MODULE_PATH. > > Yes. > >> If using a Find module then use its documentation to check the >> result. FPHSA sets FOO_FOUND. Otherwise if using Config mode >> then check Foo_FOUND. >> >> Actually, the documentation of find_package says: >> >> _FOUND will be set to indicate whether the package was found. >> >> Config mode *always* sets that. If it isn't set correctly >> by a Find module that is a bug in the Find module IMO. > > Yes. > >> FPHSA should be fixed to set both Foo_FOUND and FOO_FOUND. >> I know Alex always says that we should use UPPERCASE_VARS >> instead of ExactCase_VARS but the *ONLY* reason ever given >> is because "most" modules have done that historically. > > Yes. > Beside that I don't have any preferences whether it should be ExactCase or > UPPER_CASE, I think both naming conventions are ok. > >> That argument just extends the problem into the future as >> more and more new modules use the confusing convention. > > If we all agree consciously that going with ExactCase is ok although the > majority of existing Find-modules uses UPPER_CASE then I won't object. > > Alex > -- > > 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 I prefer exact case, too. We should adopt the convention of using exact case moving forward, and add exact case equivalents to the existing upper case ones. David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013027]: Annoying dialog box repeatedly displayed while configure step
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13027 == Reported By:Dhanannjay "Djay" Deo Assigned To: == Project:CMake Issue ID: 13027 Category: CMake Reproducibility:always Severity: minor Priority: low Status: new == Date Submitted: 2012-03-07 17:53 EST Last Modified: 2012-03-07 17:53 EST == Summary:Annoying dialog box repeatedly displayed while configure step Description: While configuring ITK nightly, Cmake displays a dialog box cmTryCompileExec.exe - System Error The program Can't start because libgcc_s_sjlj-1.dll is missing from your computer. Try reinstalling the program to fix the problem. The configuration continues, and build runs okay, but fails due to compiler error while wrapping. == Issue History Date ModifiedUsername FieldChange == 2012-03-07 17:54 Dhanannjay "Djay" DeoNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] How to handle package Config.cmake files with dependencies ?
On Wednesday 07 March 2012, Brad King wrote: > On 3/7/2012 9:49 AM, Michael Hertling wrote: > > been found, but in module mode, AFAIK, it's set to Foo_DIR-NOTFOUND > > even if a find module has succeeded > > The Foo_DIR variable is not set or added to the cache at all if > a FindFoo module is loaded regardless of whether it succeeds. > It is only if no FindFoo module is found that Foo_DIR appears. > > > my question is still: How can I figure out in a reliable manner > > that FIND_PACKAGE(Foo ...) has found neither FindFoo.cmake nor > > FooConfig.cmake? > > The call site should *know* whether it is intending to use a > Find module or look for a package config file based on whether > the the author adds a Find module to CMAKE_MODULE_PATH. Yes. > If using a Find module then use its documentation to check the > result. FPHSA sets FOO_FOUND. Otherwise if using Config mode > then check Foo_FOUND. > > Actually, the documentation of find_package says: > > _FOUND will be set to indicate whether the package was found. > > Config mode *always* sets that. If it isn't set correctly > by a Find module that is a bug in the Find module IMO. Yes. > FPHSA should be fixed to set both Foo_FOUND and FOO_FOUND. > I know Alex always says that we should use UPPERCASE_VARS > instead of ExactCase_VARS but the *ONLY* reason ever given > is because "most" modules have done that historically. Yes. Beside that I don't have any preferences whether it should be ExactCase or UPPER_CASE, I think both naming conventions are ok. > That argument just extends the problem into the future as > more and more new modules use the confusing convention. If we all agree consciously that going with ExactCase is ok although the majority of existing Find-modules uses UPPER_CASE then I won't object. Alex -- 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] Ninja windows
On Wed, Mar 7, 2012 at 5:24 PM, David Cole wrote: > On Wed, Mar 7, 2012 at 5:10 PM, Bill Hoffman wrote: >> On 3/6/2012 6:17 PM, Peter Kümmel wrote: >> >>> >>> The following tests FAILED: >>> 78 - CustomCommandWorkingDirectory (Failed) >>> 80 - BuildDepends (Failed) >>> 98 - QtAutomoc (Failed) >>> 116 - Plugin (Failed) >>> 123 - ModuleDefinition (Failed) >>> 155 - CTestTestStopTime (Failed) >>> Errors while running CTest >>> >>> >>> But it builds CMake. On more complex projects RC file rules is broken >>> ($FLAGS/$DEFINES are missing). >>> >>> A ninja binary is here, also packaged with the installer: >>> https://sourceforge.net/projects/cmakescript/files/ >>> (g...@github.com:syntheticpp/ninja.git, token-splitter branch) >>> >> >> OK, I grabbed the binary from here: >> https://sourceforge.net/projects/cmakescript/files/ >> >> Sadly, the curl abilities of cmake are not up to working with sourceforge >> download link redirection fu... >> >> Anyway, I did get the ninja.exe. I was sort of able to bootstrap cmake. >> >> I did this: >> >> 1. enable ninja on windows: >> diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt >> index eb4327c..eec3ad7 100644 >> --- a/Source/CMakeLists.txt >> +++ b/Source/CMakeLists.txt >> -if(NOT WIN32) >> +#if(NOT WIN32) >> ... >> -endif() >> +#endif() >> >> 2. build a cmake on windows with gmake >> 3. configure and build a cmake on windows with ninja. >> - configure worked >> - the build failed because the ninja generator did not create the bin >> directory in build tree. >> >> [413/430] Building CXX object >> Source\CMakeFiles\cpack.dir\CPack\cpack.cxx.obj >> FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /DWIN32 /D_WINDOWS >> /W3 /Zm1000 /EHsc /GR /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -IUtilities >> -I"C:\Users\hoffman\Work\My Builds\cmake\Utilities" -ISource >> -I"C:\Users\hoffman\Work\My Builds\cmake\Source" -IUtilities\cmcompress >> -I"C:\Users\hoffman\Work\My Builds\cmake\Source\CTest" >> -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DCURL_STATICLIB >> -DLIBARCHIVE_STATIC -DCMAKE_BUILD_WITH_CMAKE -DCMAKE_USE_NINJA /TP >> /FoSource\CMakeFiles\cpack.dir\CPack\cpack.cxx.obj /Fdbin\cpack.pdb -c >> "C:\Users\hoffman\Work\My Builds\cmake\Source\CPack\cpack.cxx" >> cpack.cxx >> >> >> If I go into the build tree and mkdir bin, then it builds. >> >> So, is this just a windows ninja thing? >> >> -Bill >> >> >> >> >> -- >> >> 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 > > > That might be fixed just now (perhaps) by stuff that I merged into > 'next' this afternoon. Try with the very latest next of CMake. (One of > the commits from Peter K. had not yet been merged into next and it > dealt with directory creation...) Or, you could try with the tip of the newest ninja-generator branch on the stage -- 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] Ninja windows
On Wed, Mar 7, 2012 at 5:10 PM, Bill Hoffman wrote: > On 3/6/2012 6:17 PM, Peter Kümmel wrote: > >> >> The following tests FAILED: >> 78 - CustomCommandWorkingDirectory (Failed) >> 80 - BuildDepends (Failed) >> 98 - QtAutomoc (Failed) >> 116 - Plugin (Failed) >> 123 - ModuleDefinition (Failed) >> 155 - CTestTestStopTime (Failed) >> Errors while running CTest >> >> >> But it builds CMake. On more complex projects RC file rules is broken >> ($FLAGS/$DEFINES are missing). >> >> A ninja binary is here, also packaged with the installer: >> https://sourceforge.net/projects/cmakescript/files/ >> (g...@github.com:syntheticpp/ninja.git, token-splitter branch) >> > > OK, I grabbed the binary from here: > https://sourceforge.net/projects/cmakescript/files/ > > Sadly, the curl abilities of cmake are not up to working with sourceforge > download link redirection fu... > > Anyway, I did get the ninja.exe. I was sort of able to bootstrap cmake. > > I did this: > > 1. enable ninja on windows: > diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt > index eb4327c..eec3ad7 100644 > --- a/Source/CMakeLists.txt > +++ b/Source/CMakeLists.txt > -if(NOT WIN32) > +#if(NOT WIN32) > ... > -endif() > +#endif() > > 2. build a cmake on windows with gmake > 3. configure and build a cmake on windows with ninja. > - configure worked > - the build failed because the ninja generator did not create the bin > directory in build tree. > > [413/430] Building CXX object > Source\CMakeFiles\cpack.dir\CPack\cpack.cxx.obj > FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /DWIN32 /D_WINDOWS > /W3 /Zm1000 /EHsc /GR /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -IUtilities > -I"C:\Users\hoffman\Work\My Builds\cmake\Utilities" -ISource > -I"C:\Users\hoffman\Work\My Builds\cmake\Source" -IUtilities\cmcompress > -I"C:\Users\hoffman\Work\My Builds\cmake\Source\CTest" > -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DCURL_STATICLIB > -DLIBARCHIVE_STATIC -DCMAKE_BUILD_WITH_CMAKE -DCMAKE_USE_NINJA /TP > /FoSource\CMakeFiles\cpack.dir\CPack\cpack.cxx.obj /Fdbin\cpack.pdb -c > "C:\Users\hoffman\Work\My Builds\cmake\Source\CPack\cpack.cxx" > cpack.cxx > > > If I go into the build tree and mkdir bin, then it builds. > > So, is this just a windows ninja thing? > > -Bill > > > > > -- > > 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 That might be fixed just now (perhaps) by stuff that I merged into 'next' this afternoon. Try with the very latest next of CMake. (One of the commits from Peter K. had not yet been merged into next and it dealt with directory creation...) -- 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] Ninja windows
On 3/6/2012 6:17 PM, Peter Kümmel wrote: The following tests FAILED: 78 - CustomCommandWorkingDirectory (Failed) 80 - BuildDepends (Failed) 98 - QtAutomoc (Failed) 116 - Plugin (Failed) 123 - ModuleDefinition (Failed) 155 - CTestTestStopTime (Failed) Errors while running CTest But it builds CMake. On more complex projects RC file rules is broken ($FLAGS/$DEFINES are missing). A ninja binary is here, also packaged with the installer: https://sourceforge.net/projects/cmakescript/files/ (g...@github.com:syntheticpp/ninja.git, token-splitter branch) OK, I grabbed the binary from here: https://sourceforge.net/projects/cmakescript/files/ Sadly, the curl abilities of cmake are not up to working with sourceforge download link redirection fu... Anyway, I did get the ninja.exe. I was sort of able to bootstrap cmake. I did this: 1. enable ninja on windows: diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt index eb4327c..eec3ad7 100644 --- a/Source/CMakeLists.txt +++ b/Source/CMakeLists.txt -if(NOT WIN32) +#if(NOT WIN32) ... -endif() +#endif() 2. build a cmake on windows with gmake 3. configure and build a cmake on windows with ninja. - configure worked - the build failed because the ninja generator did not create the bin directory in build tree. [413/430] Building CXX object Source\CMakeFiles\cpack.dir\CPack\cpack.cxx.obj FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -IUtilities -I"C:\Users\hoffman\Work\My Builds\cmake\Utilities" -ISource -I"C:\Users\hoffman\Work\My Builds\cmake\Source" -IUtilities\cmcompress -I"C:\Users\hoffman\Work\My Builds\cmake\Source\CTest" -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DCURL_STATICLIB -DLIBARCHIVE_STATIC -DCMAKE_BUILD_WITH_CMAKE -DCMAKE_USE_NINJA /TP /FoSource\CMakeFiles\cpack.dir\CPack\cpack.cxx.obj /Fdbin\cpack.pdb -c "C:\Users\hoffman\Work\My Builds\cmake\Source\CPack\cpack.cxx" cpack.cxx If I go into the build tree and mkdir bin, then it builds. So, is this just a windows ninja thing? -Bill -- 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] How to handle package Config.cmake files with dependencies ?
On 3/7/2012 9:49 AM, Michael Hertling wrote: been found, but in module mode, AFAIK, it's set to Foo_DIR-NOTFOUND even if a find module has succeeded The Foo_DIR variable is not set or added to the cache at all if a FindFoo module is loaded regardless of whether it succeeds. It is only if no FindFoo module is found that Foo_DIR appears. > my question is still: How can I figure out in a reliable manner > that FIND_PACKAGE(Foo ...) has found neither FindFoo.cmake nor > FooConfig.cmake? The call site should *know* whether it is intending to use a Find module or look for a package config file based on whether the the author adds a Find module to CMAKE_MODULE_PATH. If using a Find module then use its documentation to check the result. FPHSA sets FOO_FOUND. Otherwise if using Config mode then check Foo_FOUND. Actually, the documentation of find_package says: _FOUND will be set to indicate whether the package was found. Config mode *always* sets that. If it isn't set correctly by a Find module that is a bug in the Find module IMO. FPHSA should be fixed to set both Foo_FOUND and FOO_FOUND. I know Alex always says that we should use UPPERCASE_VARS instead of ExactCase_VARS but the *ONLY* reason ever given is because "most" modules have done that historically. That argument just extends the problem into the future as more and more new modules use the confusing convention. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] How to handle package Config.cmake files with dependencies ?
On 02/27/2012 09:15 PM, Alexander Neundorf wrote:
> Hi,
>
> I think find_package in Config mode might still need some more work.
>
> When the FooConfig.cmake has been found, Foo_FOUND is set to TRUE:
>
> // Set a variable marking whether the package was found.
> std::string foundVar = this->Name;
> foundVar += "_FOUND";
>
>
> This means it is true in all cases that the Config.cmake file has been found
> (and the version was compatible).
>
> Now I have to questions:
>
>
> * how to handle COMPONENTS ?
>
>
> If a package is requested with COMPONENTS, these should be considered for
> setting Foo_FOUND:
> find_package(Foo REQUIRED COMPONENTS A B C)
> should only succeed if A, B and C are found.
>
> This is how I would expect COMPONENTS to be handled in a FindFoo.cmake:
> (a) all components are searched by the Find-module, and each per-component
> X_Y_FOUND is set accordingly
>
> (b) there is a package-specific default subset of these components which have
> to be found to make the package found, i.e. FOO_FOUND=TRUE
>
> (c) by adding COMPONENTS to the find_package() call, these components are
> added to the set of components which have to be found to make FOO_FOUND=TRUE
>
> (d) if REQUIRED is used and FOO_FOUND is false, it errors out
Sorry for chiming in so late, but I haven't got an answer on the
users' mailing list, so I retry here. Some objections and remarks:
(1) Foo might have a non-(de)selectable unnamed core component and
an ordinary selectable component X. FIND_PACKAGE(Foo COMPONENTS X)
returning Foo_FOUND==FALSE and Foo_X_FOUND!=TRUE does not allow to
determine if the core component is available. Potential candidates
for packages like that are Qt, GTK and - most notably - SDL.
(2) FIND_PACKAGE(Foo COMPONENTS ...) returns Foo_FOUND==FALSE if a
config file has not been found - crystal. Who sets the components'
FOUND variables in this case? FIND_PACKAGE() on its own behalf? If
so, note [1] and think of the same uncertainty w.r.t. components:
FIND_PACKAGE() on its own might return with Foo_bar_FOUND whereas
the config file sets Foo_Bar_FOUND. Leaving the components' FOUND
variables untouched? Note [2]. IMO, Brad is absolutely right *not*
to assume that Foo_FOUND was undefined before FIND_PACKAGE() ran.
So, concerning Foo_Bar_FOUND, one should also not rely on that
assumption, but your approach can't guarantee this, AFAICS.
(3) Suppose a component Y is added to Foo in a later release. Run
against such a release, FIND_PACKAGE(Foo COMPONENTS Y) is perfect,
but would face an older FooConfig.cmake with an unknown component
Y. Thus, "all components are searched" should read "all requested
components are searched", the known ones are enabled, and for the
unknown ones, just the respective FOUND variable is set to FALSE.
Personally, my favored approach for {FindFoo,FooConfig}.cmake is:
- Set a FOUND variable for each requested component, known or not.
- Foo_FOUND==FALSE: Foo totally unavailable, don't use it in any
manner. In particular, do not use any further Foo_* variables.
- Foo_FOUND==TRUE: Foo basically available, but no information
about components. Check their availability by the respective
FOUND variable, e.g. IF(Foo_FOUND AND Foo_Bar_FOUND).
For the user, this means:
- Request all components that will be used.
- Use only components that have been requested.
IMO, this approach is robust, versatile and anything but difficult
to implement, and it does not require any change in FIND_PACKAGE().
Regards,
Michael
[1] http://www.mail-archive.com/cmake-developers@cmake.org/msg03036.html
[2] http://www.mail-archive.com/cmake-developers@cmake.org/msg03085.html
--
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] How to handle package Config.cmake files with dependencies ?
On 02/27/2012 10:05 PM, Brad King wrote: > On 2/27/2012 3:37 PM, Michael Wild wrote: >> On 02/27/2012 09:15 PM, Alexander Neundorf wrote: >>> When the FooConfig.cmake has been found, Foo_FOUND is set to TRUE: >>> >>> // Set a variable marking whether the package was found. >>>std::string foundVar = this->Name; >>>foundVar += "_FOUND"; >>> >>> This means it is true in all cases that the Config.cmake file has been found >>> (and the version was compatible). > > The find_package command is acting as a primitive like find_library from > the point of view of setting Foo_DIR, and that can be tested directly to > see if the config file was found. That leaves room to change the way > we set Foo_FOUND. We could add a policy that in NEW behavior unsets > Foo_FOUND completely before loading FooConfig. After FooConfig has been > loaded it detects whether Foo_FOUND is now defined. If set, use that > value. If not set, set it to true as it is now. That will give the > FooConfig file a chance to set the result. Some FooConfig.cmake authors might use FPHSA(Foo "..." ...) because of its messaging capabilities respecting REQUIRED/QUIET, and rely on FIND_PACKAGE() returning with Foo_FOUND==TRUE even if FPHSA() has set this variable to FALSE. Note that there is still no convention which could deprecate this kind of FPHSA()'s usage in config files. Since the proposed approach will break things in such a case, a policy would actually be necessary, IMO. Regarding Foo_DIR: This suits to determine if FooConfig.cmake has been found, but in module mode, AFAIK, it's set to Foo_DIR-NOTFOUND even if a find module has succeeded. Similarly, Foo_CONFIG is empty in module mode or if FooConfig.cmake hasn't been found. Therefore, my question is still: How can I figure out in a reliable manner that FIND_PACKAGE(Foo ...) has found neither FindFoo.cmake nor FooConfig.cmake? Anyway, I have difficulties to realize the advantages of the proposed approach. What does work better with it? Where is Foo_FOUND = Foo_X_FOUND && Foo_Y_FOUND && ... superior to the status quo? Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013024]: some ctest svn calls may hang waiting for user input
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13024 == Reported By:ngladitz Assigned To: == Project:CMake Issue ID: 13024 Category: CTest Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-03-07 10:22 EST Last Modified: 2012-03-07 10:22 EST == Summary:some ctest svn calls may hang waiting for user input Description: The certificate (https) on our svn server was replaced and no longer trusted on some of the cdash build clients resulting in ctest svn calls asking for user input. The call to "svn update" passes "--non-interactive" maybe this should be passed to all svn commands issued by ctest. The specific command that was hanging for me was "svn log --xml [...]". If possible I'd also like to optionally add --trust-server-cert to all svn invocations. == Issue History Date ModifiedUsername FieldChange == 2012-03-07 10:22 ngladitz New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
