Re: [cmake-developers] Bug introduced in generate-time target checking code
Brad King wrote: > On 10/16/2012 08:43 AM, Stephen Kelly wrote: >> Still, some of the platforms fail the test, and don't give any >> information about why: >> >> http://open.cdash.org/testSummary.php?project=1&name=GeneratorExpression&date=2012-10-16 >> >> Can someone please provide more information (backtrace or further >> investigation) for one of the failing platforms? > > Borland Make and NMake both have an inline file syntax that starts with > "<<": > > http://msdn.microsoft.com/en-us/library/z440c98k.aspx > > The custom command generated by this test accidentally triggers that. > I don't know if there is a way to escape it. It's probably simplest > for your purposes to just do something else in the test. > The '<<' is exactly what the test is testing, so I'll just remove the offending tests. Thanks for looking into it, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bug introduced in generate-time target checking code
On 10/16/2012 08:43 AM, Stephen Kelly wrote: > Still, some of the platforms fail the test, and don't give any information > about why: > > http://open.cdash.org/testSummary.php?project=1&name=GeneratorExpression&date=2012-10-16 > > Can someone please provide more information (backtrace or further > investigation) for one of the failing platforms? Borland Make and NMake both have an inline file syntax that starts with "<<": http://msdn.microsoft.com/en-us/library/z440c98k.aspx The custom command generated by this test accidentally triggers that. I don't know if there is a way to escape it. It's probably simplest for your purposes to just do something else in the test. -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] Bug introduced in generate-time target checking code
Stephen Kelly wrote: > Stephen Kelly wrote: > >> Stephen Kelly wrote: >>> None of the outputs have a backtrace. Any idea why? Can a backtrace be >>> provided? Reading the code, I'm not seeing which iteration is going past >>> the end. >> >> I added some asserts and found that the problem is in iterating over >> comma tokens somehow. I'll see about fixing it. > > I wrote a topic to attempt to fix this, but it seems to have had mixed > results. Bcc still fails, vs10 passes, but has a new failure in > RunCMake.TargetPropertyGeneratorExpressions: > > http://open.cdash.org/viewTest.php?onlyfailed&buildid=2614187 > > http://open.cdash.org/viewTest.php?onlydelta&buildid=2614232 > > I'm not sure if the new failure is the result of the merge or not. I'd > probably need a backtrace to diagnose the bcc failure. > The RunCMake.TargetPropertyGeneratorExpressions failure was probably a side- effect of the incremental builds of the Continuous configuration. Still, some of the platforms fail the test, and don't give any information about why: http://open.cdash.org/testSummary.php?project=1&name=GeneratorExpression&date=2012-10-16 Can someone please provide more information (backtrace or further investigation) for one of the failing platforms? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bug introduced in generate-time target checking code
Stephen Kelly wrote: > Stephen Kelly wrote: >> None of the outputs have a backtrace. Any idea why? Can a backtrace be >> provided? Reading the code, I'm not seeing which iteration is going past >> the end. > > I added some asserts and found that the problem is in iterating over comma > tokens somehow. I'll see about fixing it. I wrote a topic to attempt to fix this, but it seems to have had mixed results. Bcc still fails, vs10 passes, but has a new failure in RunCMake.TargetPropertyGeneratorExpressions: http://open.cdash.org/viewTest.php?onlyfailed&buildid=2614187 http://open.cdash.org/viewTest.php?onlydelta&buildid=2614232 I'm not sure if the new failure is the result of the merge or not. I'd probably need a backtrace to diagnose the bcc failure. Anyway, this should be unrelated to the fix-NOTFOUND-processing branch. The fix-INCLUDE_DIRECTORIES-multiconfig is also important for the release I think, but I haven't tested it with the multi-config generators. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bug introduced in generate-time target checking code
Stephen Kelly wrote: > None of the outputs have a backtrace. Any idea why? Can a backtrace be > provided? Reading the code, I'm not seeing which iteration is going past > the end. I added some asserts and found that the problem is in iterating over comma tokens somehow. I'll see about fixing it. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bug introduced in generate-time target checking code
Brad King wrote:
> On 10/15/2012 04:54 AM, Stephen Kelly wrote:
>> Stephen Kelly wrote:
>>> Thoughts?
>>>
>>
>> I've pushed a fix-NOTFOUND-processing branch to next. It preprocesses the
>> INCLUDE_DIRECTORIES property content to remove generator expressions
>> before checking them. This way, all entries which are well-defined at
>> configure- time will still report an error as before.
>
> Thanks for working on the fix, but the GeneratorExpression test is failing
> on Windows builds so it cannot be merged to master yet.
That's failing in the nightlies, so it's coming from a branch I merged
before ('generator-expression-bug-fixes').
None of the outputs have a backtrace. Any idea why? Can a backtrace be
provided? Reading the code, I'm not seeing which iteration is going past the
end.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bug introduced in generate-time target checking code
On 10/15/2012 04:54 AM, Stephen Kelly wrote: > Stephen Kelly wrote: >> Thoughts? >> > > I've pushed a fix-NOTFOUND-processing branch to next. It preprocesses the > INCLUDE_DIRECTORIES property content to remove generator expressions before > checking them. This way, all entries which are well-defined at configure- > time will still report an error as before. Thanks for working on the fix, but the GeneratorExpression test is failing on Windows builds so it cannot be merged to master yet. -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] Bug introduced in generate-time target checking code
Stephen Kelly wrote: > Thoughts? > I've pushed a fix-NOTFOUND-processing branch to next. It preprocesses the INCLUDE_DIRECTORIES property content to remove generator expressions before checking them. This way, all entries which are well-defined at configure- time will still report an error as before. For entries which are only evaluated at generate-time, we'll still need a solution in the following release I think. This is somewhat related to [1] because I'll be changing how linking works then too. [1] http://public.kitware.com/Bug/view.php?id=13588 Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Bug introduced in generate-time target checking code
Stephen Kelly wrote:
>
> Hi there,
>
> I just noticed that I probably introduced a bug in commit
> 290e92ada86c5b74669be48ee901494ae8e48ee3. I don't have time to fix it or
> even test it right now, but in that commit I changed a call to GetTargets
> into GetGeneratorTargets in cmGlobalGenerator::CheckLocalGenerators. The
> problem is that CheckLocalGenerators is called at configure time, so the
> GeneratorTargets is still empty.
>
> Can CheckLocalGenerators be invoked at generate time instead? It calls
> GetOriginalLinkLibraries, which I also need to call only at generate-time
> as it will need to be moved to cmGeneratorTarget and use generator
> expressions.
I have now tested and confirmed the issue.
This CMakeLists file no longer produces a configure-time error in master,
though it does with the stable version:
cmake_minimum_required(VERSION 2.8)
include_directories(SOMETHING_INCLUDE_DIRS-NOTFOUND)
CMake Error: The following variables are used in this project, but they are
set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake
files:
SOMETHING_INCLUDE_DIRS
used as include directory in directory
/home/stephen/dev/src/playground/cmake
-- Configuring incomplete, errors occurred!
Similarly, the Qt and curses guis No longer flag the NOTFOUND include
directories after selecting the 'configure' action, but fail at compile time
instead.
The reason for this is as I described above. The code now loops over
cmGeneratorTargets - a container which is not populated at configure-time.
Part of the problem is that the include directories could be determined only
at generate-time, not at configure-time. A similar issue will arise with
processing linked libraries (which is how I noticed it).
This means that the cmake-gui workflow of pressing the configure button
until there is no more red, then generating will no longer be valid. As
dependencies can be determined to be NOTFOUND at generate-time, hitting the
'Generate' button could generate new red entries in the view.
Additionally, all CONFIGURATIONS will need to be iterated over and tested
whether they produce any NOTFOUND content.
This also raises the larger issue of generate-time errors. If an error
occurs at configure-time, the generate step is not executed, and the build-
system is not generated - make does nothing. If an error occured at
generate-time, generation does not abort, and although a 'fatal' error can
be reported, make can still execute, and depending on the nature of the
error, may succeed or fail.
It might make sense to generate no top-level makefile or a top-level
makefile which only reports the same error that was reported at generate-
time if that is something that has an equivalent with all generators. Eg,
something like:
all:
${CMAKE_COMMAND} -E echo "SOMETHING_INCLUDE_DIRS used in this
project, but set to NOTFOUND"
I think that's one of the options for fixing this.
Given that we're in RC mode and expecting to release final in two weeks, one
other option is to revert part of the branch adding the feature. Then we'd
still have to solve the problems for the next release anyway, but with more
time to research and prepare.
Thoughts?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Bug introduced in generate-time target checking code
Hi there, I just noticed that I probably introduced a bug in commit 290e92ada86c5b74669be48ee901494ae8e48ee3. I don't have time to fix it or even test it right now, but in that commit I changed a call to GetTargets into GetGeneratorTargets in cmGlobalGenerator::CheckLocalGenerators. The problem is that CheckLocalGenerators is called at configure time, so the GeneratorTargets is still empty. Can CheckLocalGenerators be invoked at generate time instead? It calls GetOriginalLinkLibraries, which I also need to call only at generate-time as it will need to be moved to cmGeneratorTarget and use generator expressions. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
