Re: [cmake-developers] conditionals in generator expressions
Stephen Kelly wrote: >> The destructor of cmCompiledGeneratorExpression is deleting >> the evaluators before they get used again in later evals. >> Commenting out the "delete" line fixes the crash but probably >> leaks. You need to work out the ownership semantics. >> > > Thanks. I'm too used to everything being implicitly shared :). Valgrind > didn't show the problem, interestingly enough. A colleague tells me that gcc generates code that doesn't actually 'guard' memory immediately when the dtor is called, but Windows does, which could explain everything. 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] Exporting dependent library targets in multiple export sets
On 09/15/2012 04:45 PM, Alexander Neundorf wrote: > There is now a branch export-sets-2 on cmake stage. > It cherry-picks a lot of the patches from > http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set, mostly > those from May, and then proceeds a bit differently. > > In the end, cmake now checks whether a target which is missing in the current > export set has been exported and installed exactly once, gets the correct > name > from that one installation (i.e. the used namespace), and uses that. That simple approach will allow us to move forward with this. If anyone wants multiple exports of the same targets then they can add the explicit export set DEPENDS options later. The topic looks good except for the details below. > Additionally it puts the following check in the generated target file: > > IF(NOT TARGET "Foo::foo" ) > MESSAGE(FATAL_ERROR "Required imported target \"Foo::foo\" not found ! ") > ENDIF() > > Please review the branch. > Exotic cases are not supported, but it should be possible now to export > libraries in separate export sets and still have it work. > > I guess I have to handle the error case better than simply erroring out. Not IMO. Remember my message here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4374/focus=4386 The user has the option to specify a known-working _DIR value or disable use of the package completely. Your commit message sentence "I guess instead of completely erroring out it would be better to only make the find_package() fail." is not needed. Also, one of Yury's commit messages says: TODO: remove another clear() because it doesn't delete TargetExports. What is that about? Thanks, -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] conditionals in generator expressions
Stephen Kelly wrote: > Good idea. Pushed to next with this modification. > I've fixed all errors and warnings that can be fixed. Some remain due to compiler bugs which claim some code in a template is unreachable (but that's only due to the template parameters). I think it would make sense to rewrite the branch to squash the whitespace fixes before merging to master though. 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] conditionals in generator expressions
Stephen Kelly wrote: >>> The next thing I want to do is to see if I can make full use of >>> cmGeneratorTarget and use const proactively while doing so, to make the >>> code more clear. I'm not 100% certain that's possible, but it's the next >>> goal I have. Any comments on that? >> >> That would be a really great example of splitting configure-time >> constructs from generate-time constructs. > > Right. I investigated a little bit already and it seems there's at least > some low-hanging fruit. I've put my work on the use-generator-target branch in my clone. Using const as proactively as I wanted is not really possible/worth it because of all the memoizing cmake does, but I've ported it to use cmGeneratorTarget enough to be able to add a cmGeneratorTarget::GetCompileDefinitions(const char *config) and use generator expressions in the implementation, and to use generator expressions in cmGeneratorTarget::GetIncludeDirectories(const char *config) too. That should be three trivial patches, but I haven't written them yet. That's all I'm aiming for of the target_use_targets feature for the next release, so I think that's still on track. 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] conditionals in generator expressions
Stephen Kelly wrote: > too. That should be three trivial patches, but I haven't written them yet. > That's all I'm aiming for of the target_use_targets feature for the next > release, so I think that's still on track. I spoke too soon. It's 3 trivial patches and one DAG-checker. :) http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements#TODO 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] [CMake 0013544]: Visual Studio 2012 Express not supported
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13544 == Reported By:Filip Konvicka (LOGIS) Assigned To: == Project:CMake Issue ID: 13544 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-09-17 09:32 EDT Last Modified: 2012-09-17 09:32 EDT == Summary:Visual Studio 2012 Express not supported Description: Visual C++ 2012 Express is not detected properly. The registry paths (and possibly other things) in the Express version differ from the paid MSVS versions. Additional Information: The new registry path is HKEY_CURRENT_USER\\Software\\Microsoft\\WDExpress\\11.0_Config Also, the IDE exe name is no longer VCExpress.exe, but rather WDExpress.exe. == Issue History Date ModifiedUsername FieldChange == 2012-09-17 09:32 Filip Konvicka (LOGIS)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
Re: [cmake-developers] conditionals in generator expressions
On 09/17/2012 08:50 AM, Stephen Kelly wrote:
> I've fixed all errors and warnings that can be fixed. Some remain due to
> compiler bugs which claim some code in a template is unreachable (but that's
> only due to the template parameters).
The HP warnings are not a compiler bug. It looks like other compilers
picked up on it too but you suppressed the warnings in the topic.
In this code:
template
...
// TODO: static_assert(!(name && dir))
if(nameQual)
{
return cmSystemTools::GetFilenameName(result);
}
else if (dirQual)
{
return cmSystemTools::GetFilenamePath(result);
}
return result;
when either nameQual or dirQual is true that is a compile-time constant
so the "return result" line is truly unreachable in that instantiation.
You need to use compile-time conditional code rather than "runtime"
tests of compile-time constants. This is true for the other template
parameters too.
> I think it would make sense to rewrite the branch to squash the whitespace
> fixes before merging to master though.
Yes, I can do this when the topic is done.
-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] Specifying VS target platform
On 09/14/2012 05:59 PM, Patrick Gansterer wrote:
> Maybe you can merge the first patch already.
Yes, done.
>> The idea of a "generator platform" is not generic among all generators.
>> Rather than the general CMAKE_GENERATOR_PLATFORM infrastructure I'd
>> generator-specific handling. The value of -GP should be passed to the
>> global generator created from -G. If the generator does not support
>> platform specification in this way then -GP should be an error (all
>> generators except VS >= 8). If the generator does support -GP then it
>> should do its own thing to save the value. For VS save it in a cache
>> entry like "CMAKE_VS_PLATFORM" (we have "CMAKE_VS_PLATFORM_TOOLSET"
>> already for the VS 10 toolchain in some cases).
>
> I'm not a big fan of your ideas: What about the parts where we
> pass the generator platform to other parts? Do we want to add
> branches for every generator type to get get correct value for
> the -GP parameter (e.g. if (CMAKE_GENERATOR == "Visual Studio
> ...") "-GP ${CMAKE_VS_PLATFORM}")? IMHO that's not a good
> idea. Also handling for making sure that generator platform
> isn't changed by the user (like we do for -G already) in a
> second run of CMake must be duplicated later if we add -GP to
> more than one generator. (and so on...)
Good points, but we still need to reject -GP when using generators
for which it does not make sense. I think it may be moot anyway;
see below.
>> I realized that existing projects may test ${CMAKE_GENERATOR} to look
>> for things like "Win64". For compatibility we need to make sure that
>>
>> -G "Visual Studio 10" -GP x64
>>
>> results in CMAKE_GENERATOR being set to
>>
>> -G "Visual Studio 10 Win64"
>>
>> while processing CMake code even if it is not used that way
>> internally. Of course for future VS versions the generator names
>> will not need to work this way, only the existing ones.
>
> Since we need to support -G "Visual Studio 10 Win64" anyway, I don't see
> much problem if such cases will work with -G "Visual Studio 10 Win64",
> but not with -G "Visual Studio 10" -GP x64.
We are talking about changing the way the user selects the generator
in the GUI to be equivalent to -G/-GP. We cannot process existing
projects differently depending on how the generator was selected.
I also know there are projects that pass ${CMAKE_GENERATOR} to
internal invocations of CMake in order to say "build it like I'm
built". These paths would not work if any information moved over
to CMAKE_GENERATOR_PLATFORM or an equivalent variable.
I think the value of -GP has to be stored in CMAKE_GENERATOR at
the end of the generator name as it is now. The new option and GUI
updates are really just about simplifying the selection of the
generator and avoiding per-platform global generators in the internal
implementation. Users can either use -G and specify the full
generator name with platform or use -G/-GP separately but either way
the value of CMAKE_GENERATOR will be the same.
This can probably be improved in the future with a new cmake policy
but I don't want to open that can of worms just for WinCE. I think
you can implement -G/-GP such that the values are both stored in the
CMAKE_GENERATOR value. Internally we won't need a separate global
generator for every platform anymore, but that does not change the
public interface.
Thanks,
-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] conditionals in generator expressions
Brad King wrote: > when either nameQual or dirQual is true that is a compile-time constant > so the "return result" line is truly unreachable in that instantiation. Yes. I was assuming a compiler optimization would exist for that kind of thing. > You need to use compile-time conditional code rather than "runtime" > tests of compile-time constants. This is true for the other template > parameters too. Done. 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] Exporting dependent library targets in multiple export sets
2012/9/17 Brad King : > On 09/15/2012 04:45 PM, Alexander Neundorf wrote: > Also, one of Yury's commit messages says: > > TODO: remove another clear() because it doesn't delete TargetExports. > > What is that about? clear() on a vector of TargetExport* does not call delete on each element. BTW, do we really support the reinitialization of all cmake structures? I think that there are quite a few memory leaks in this case. -- Yours Yury, mailto: urkud.ur...@gmail.com -- 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] Exporting dependent library targets in multiple export sets
2012/9/16 Alexander Neundorf : > On Tuesday 11 September 2012, Brad King wrote: >> On 09/11/2012 04:08 PM, Yury G. Kudryashov wrote: >> > 2012/9/11 Alexander Neundorf : >> >> Hi Yury, >> >> >> >> will you be able to work on this for the 2.8.10 release ? >> > >> > What are the deadlines? >> >> Features not finished by the end of September may not be included. > > I gave it a try today. Thanks a lot! I had a lot of bureaucratic work last week, and did not know if it will be finished soon. It seems that each Russian bureaucrat wants to let citizens do much more paper work than it is written in the law... The only way to resist is to cite the law or give them a printed version to read. It would be nice if you'll give me a couple of days to review your branch. If I'll become silent again, just go on. -- Yours Yury, mailto: urkud.ur...@gmail.com -- 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] Proposal: An IRC dev meeting to chat about CMake stuff
Please join us in about 15 minutes for a CMake Developers chat via the IRC #cmake room... -- 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] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Brad King wrote: > On 09/15/2012 04:45 PM, Alexander Neundorf wrote: > > There is now a branch export-sets-2 on cmake stage. > > It cherry-picks a lot of the patches from > > http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set, > > mostly those from May, and then proceeds a bit differently. > > > > In the end, cmake now checks whether a target which is missing in the > > current export set has been exported and installed exactly once, gets > > the correct name from that one installation (i.e. the used namespace), > > and uses that. > > That simple approach will allow us to move forward with this. If anyone > wants multiple exports of the same targets then they can add the explicit > export set DEPENDS options later. Cool. The tests are not yet passing, I'll work on this. > The topic looks good except for the details below. > > > Additionally it puts the following check in the generated target file: > > > > IF(NOT TARGET "Foo::foo" ) > > > > MESSAGE(FATAL_ERROR "Required imported target \"Foo::foo\" not found ! > > ") > > > > ENDIF() > > > > Please review the branch. > > Exotic cases are not supported, but it should be possible now to export > > libraries in separate export sets and still have it work. > > > > I guess I have to handle the error case better than simply erroring out. > > Not IMO. Remember my message here: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4374/focu > s=4386 > > The user has the option to specify a known-working _DIR value or > disable use of the package completely. Your commit message sentence > "I guess instead of completely erroring out it would be better to only > make the find_package() fail." is not needed. I think this is different. Here, in this case, it may fail because the required (missing) package was simply not found, because it is not installed. If the package is optional, this is ok, cmake should not abort, but just report that the package was not found. In the referenced email, if the error occurs, something is broken on the system, a broken package has been installed, or something like that. This is IMO different than simply a missing package. 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] Exporting dependent library targets in multiple export sets
On 09/17/2012 03:14 PM, Alexander Neundorf wrote: > On Monday 17 September 2012, Brad King wrote: >>> I guess I have to handle the error case better than simply erroring out. >> >> Not IMO. Remember my message here: > > I think this is different. > Here, in this case, it may fail because the required (missing) package was > simply not found, because it is not installed. I must not understand the use case. It looks to me like you're generating a Targets.cmake file to be loaded by a Config.cmake file. If these files are being read then _DIR is set to a copy of the . The package has been found. Just as in the previous discussion, the error in the package occurs because it is misconfigured: one of its dependencies is not installed or loaded correctly to provide the other imported target. -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] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Brad King wrote: > On 09/17/2012 03:14 PM, Alexander Neundorf wrote: > > On Monday 17 September 2012, Brad King wrote: > >>> I guess I have to handle the error case better than simply erroring > >>> out. > >> > >> Not IMO. Remember my message here: > > I think this is different. > > Here, in this case, it may fail because the required (missing) package > > was simply not found, because it is not installed. > > I must not understand the use case. It looks to me like you're generating > a Targets.cmake file to be loaded by a Config.cmake file. If > these files are being read then _DIR is set to a copy of the . > The package has been found. Just as in the previous discussion, the > error in the package occurs because it is misconfigured: one of its > dependencies is not installed or loaded correctly to provide the other > imported target. Let's say FooTargets.cmake provides the target foo. BarTargets.cmake provides the target bar, and requires FooTargets.cmake. Now if the user installed the bar-devel package, but not the foo-devel package, the target foo will not be available. This can or should be checked also outside maybe in the BarConfig.cmake cmake, which could load BarTargets.cmake only if Foo could be found, but still I think it's not necessary to abort in this error case. 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] Exporting dependent library targets in multiple export sets
On 09/17/2012 03:35 PM, Alexander Neundorf wrote: > Let's say FooTargets.cmake provides the target foo. > > BarTargets.cmake provides the target bar, and requires FooTargets.cmake. > > Now if the user installed the bar-devel package, but not the foo-devel > package, the target foo will not be available. > This can or should be checked also outside maybe in the BarConfig.cmake > cmake, > which could load BarTargets.cmake only if Foo could be found, but still I > think it's not necessary to abort in this error case. What would you do instead of aborting? Silently pretend the package Bar was not found at the current Bar_DIR and move on with the search? That would require the sandboxing I previously elaborated. It would also be confusing to users IMO because the package they know is in their search path would be skipped for a mysterious reason. -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] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Brad King wrote: > On 09/17/2012 03:35 PM, Alexander Neundorf wrote: > > Let's say FooTargets.cmake provides the target foo. > > > > BarTargets.cmake provides the target bar, and requires FooTargets.cmake. > > > > Now if the user installed the bar-devel package, but not the foo-devel > > package, the target foo will not be available. > > This can or should be checked also outside maybe in the BarConfig.cmake > > cmake, which could load BarTargets.cmake only if Foo could be found, but > > still I think it's not necessary to abort in this error case. > > What would you do instead of aborting? Silently pretend the package > Bar was not found at the current Bar_DIR and move on with the search? > That would require the sandboxing I previously elaborated. It would > also be confusing to users IMO because the package they know is in > their search path would be skipped for a mysterious reason. Isn't e.g. FindPNG.cmake doing just the same ? If zlib wasn't found, fail at finding png. Here we are again at generating error messages... Instead of simply stating that a required target does not exist, it could also state from which installed export this is expected to come, e.g. FooTargets.cmake. 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] Exporting dependent library targets in multiple export sets
On 09/17/2012 03:52 PM, Alexander Neundorf wrote: > On Monday 17 September 2012, Brad King wrote: >> What would you do instead of aborting? Silently pretend the package >> Bar was not found at the current Bar_DIR and move on with the search? >> That would require the sandboxing I previously elaborated. It would >> also be confusing to users IMO because the package they know is in >> their search path would be skipped for a mysterious reason. > > Isn't e.g. FindPNG.cmake doing just the same ? > If zlib wasn't found, fail at finding png. Okay, so then BarConfig.cmake would set Bar_FOUND to false to pretend the package isn't found but not change Bar_DIR? > Instead of simply stating that a required target does not exist, it could > also > state from which installed export this is expected to come, e.g. > FooTargets.cmake. That would be useful if the namespace doesn't match. -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] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Brad King wrote: > On 09/17/2012 03:52 PM, Alexander Neundorf wrote: > > On Monday 17 September 2012, Brad King wrote: > >> What would you do instead of aborting? Silently pretend the package > >> Bar was not found at the current Bar_DIR and move on with the search? > >> That would require the sandboxing I previously elaborated. It would > >> also be confusing to users IMO because the package they know is in > >> their search path would be skipped for a mysterious reason. > > > > Isn't e.g. FindPNG.cmake doing just the same ? > > If zlib wasn't found, fail at finding png. > > Okay, so then BarConfig.cmake would set Bar_FOUND to false to pretend > the package isn't found but not change Bar_DIR? Something like that. 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] Proposal: An IRC dev meeting to chat about CMake stuff
David Cole wrote: > Please join us in about 15 minutes for a CMake Developers chat via the IRC > #cmake room... Here is the log of the meeting. [19:47:56] ah, the VIPs are finally arriving ;) [19:48:36] *** Modus #cmake +o Dakon durch ChanServ [19:48:47] *** Modus #cmake +v davidcole durch Dakon [19:58:01] VIP? Where? (looks around… sees nobody else) [19:58:13] ;) [19:58:26] aLeSD|: there? [19:59:38] Can we tell how many are here? I'm not an IRC expert yet by any stretch [20:00:30] I'm here for the developer discussion. [20:00:42] davidcole: 84 people [20:00:49] But it's always about that many [20:00:52] Excellent, you are in the right place [20:01:28] This is going to be sort of free form… [20:01:37] I don't have any specific agenda [20:02:35] But I would like to talk about CMake 2.8.10, when we should anticipate having release candidate 1, talk a little about bugs, and then see if anybody else has any questions or discussion items [20:04:38] then let's talk ;) [20:05:50] OK - first of all, one of the ideas with scheduling this on Monday was to talk about anything you all would like to bring to my attention (and Brad's) before our Tuesday merge sessions. [20:06:20] Before we talk about 2.8.10-rc1, does anybody have any specific items that they want to chat about w.r.t. tomorrow's merging? [20:06:26] I have an item: Is the qt5-qtdialog-port branch blocked on something? Waiting for Qt 5 relase or something like thaT? [20:06:35] The dashboard looks good today. [20:06:51] qt5 question: hang on, let me take a glance at it... [20:07:40] Oops, I just realized I didn't merge it to next... [20:07:44] I think I finally fixed the last issue in the document-MSVC- variables-12567 branch, should be green tomorrow [20:07:48] The "qt5-qtdialog-port" is not merged to 'next' according to 'stage print' [20:08:11] One of these times I'll look up to see what others have typed before I hit "return" :-P [20:08:21] hrhr [20:08:40] I have a fix in bug 13262 but got no response from the original reporter so far [20:08:41] great on the "fixing last issue" - thanks, Eike [20:09:16] I think I'll just push and merge that to next now and let everyone complain afterwards about the things I broke again ;) [20:09:16] well…. [20:09:29] Merged the qt5 branch to next now. [20:09:40] w.r.t. 13262, if you don't hear back, but you think it's probably the right fix, it's ok with me if you want to merge it to 'next' [20:10:08] the patch for it looks simple enough [20:10:42] I think I once again will run into problems there is the list is empty, no? [20:10:58] will check and then merge [20:11:39] ah, no, the list can't be empty there [20:12:11] but I'll change that "set" to "list(APPEND" for sanity [20:12:31] sounds reasonable [20:12:42] there are other "not yet in next [20:12:48] " branches on the stage [20:13:17] any claimers? for "export-sets-2" "generate_export_header-fixes" and "AutomocUseTargetProperties" [20:13:36] will they be in 'next' soon? Or is the stage being used as a communications channel for these topics? [20:14:01] the second one sounds like steveire ;) [20:14:03] generate_export_header-fixes is mine. I'll try to come back to it soon [20:14:24] The last time I merged it, the dashboard blushed. [20:14:37] It was embarrassed for you? [20:14:38] '-) [20:14:40] ;-) [20:14:59] Looks like export-sets-2 is Alex's [20:15:00] :) [20:15:18] Yes, that's under discussion on the ml atm. [20:15:22] someone could have noticed that I messed up the argument order to list(FIND) in that patch [20:15:30] http://public.kitware.com/Bug/view.php?id493#c30781 relates to the third one. [20:15:31] And so is the other one (also Alex's) [20:15:58] Dang, do I have to look up the --help-command for list everytime? [20:16:45] hehe ;) [20:17:01] why should it be simpler for you than for me, hm? ;) [20:17:08] All right, so it sounds like things are fairly well in hand for topics already in 'next' and topics coming soon on the stage [20:17:53] I would like if Brad could go and cherry-pick that kwsys stuff from VTK he talked about [20:17:58] Assuming the dashboards look good tomorrow, Brad and I will review them all and hopefully push most or all of them to master [20:18:26] I will mention the kwsys/VTK item to him [20:20:33] can someone try to load one of the Windows machines with a bunch of open source projects? [20:21:04] I fear that most Find modules are not tested on windows at all and will explode once someone will test them [20:22:00] What do you mean by "load with a bunch"? [20:22:30] It's really a delicate balancing act trying not to mess up a dashboard machine that's already successfully submitting for multiple projects. [20:22:53] I tend to avoid installing stuff unless it's absolutely necessary on the stable dashboard machines. [20:23:04] I can see your point, though [20:23:20] Just not sure how to achieve the goal without becoming responsible for "other people' [20:23:24] s dashb
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Brad King wrote: > On 09/15/2012 04:45 PM, Alexander Neundorf wrote: > > There is now a branch export-sets-2 on cmake stage. > > It cherry-picks a lot of the patches from > > http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set, > > mostly those from May, and then proceeds a bit differently. > > > > In the end, cmake now checks whether a target which is missing in the > > current export set has been exported and installed exactly once, gets > > the correct name from that one installation (i.e. the used namespace), > > and uses that. > > That simple approach will allow us to move forward with this. If anyone > wants multiple exports of the same targets then they can add the explicit > export set DEPENDS options later. > > The topic looks good except for the details below. How should the APPEND mode of EXPORT() be handled ? Could you please have a look at cmExportFileGenerator::SetImportLinkProperty(..) whether this looks ok ? 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] Exporting dependent library targets in multiple export sets
On Mon, Sep 17, 2012 at 4:35 PM, Alexander Neundorf wrote: > How should the APPEND mode of EXPORT() be handled ? > Could you please have a look at > cmExportFileGenerator::SetImportLinkProperty(..) > whether this looks ok ? The APPEND mode used to mean the project is on its own to handle dependencies. I guess it can get the target from another export if it is already there but otherwise not produce any error. -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] Proposal: An IRC dev meeting to chat about CMake stuff
Hi, sorry, I totally forgot about the IRC meeting. On Monday 17 September 2012, Rolf Eike Beer wrote: > 20:13:17] any claimers? for "export-sets-2" Working on it right now. > "generate_export_header-fixes" and "AutomocUseTargetProperties" Oh, I haven't merged that to next yet ? Will do so. > [20:37:59] We have about 30-something on the roadmap > [20:38:05] and I doubt we'll get to them all > [20:38:18] we have fixed 24 according to the change log page > since Aug. 9th Yes, I was hoping to be able to fix the remaining open Eclipse-related bugs, but except one they are all due to issues inside Eclipse :-/ 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] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Alexander Neundorf wrote: > On Monday 17 September 2012, Brad King wrote: > > On 09/15/2012 04:45 PM, Alexander Neundorf wrote: > > > There is now a branch export-sets-2 on cmake stage. > > > It cherry-picks a lot of the patches from > > > http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set, > > > mostly those from May, and then proceeds a bit differently. > > > > > > In the end, cmake now checks whether a target which is missing in the > > > current export set has been exported and installed exactly once, gets > > > the correct name from that one installation (i.e. the used namespace), > > > and uses that. > > > > That simple approach will allow us to move forward with this. If anyone > > wants multiple exports of the same targets then they can add the explicit > > export set DEPENDS options later. > > Cool. > The tests are not yet passing, I'll work on this. The tests are passing now. I had to change the order how the target files are included in the test, so that the required targets already exist when the other targets are set up. I pushed that to stage too. I think basically we're back to generating useful error messages again... 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] Specifying VS target platform
On Mon, 17 Sep 2012 09:57:28 -0400, Brad King wrote:
On 09/14/2012 05:59 PM, Patrick Gansterer wrote:
Maybe you can merge the first patch already.
Yes, done.
The idea of a "generator platform" is not generic among all
generators.
Rather than the general CMAKE_GENERATOR_PLATFORM infrastructure I'd
generator-specific handling. The value of -GP should be passed to
the
global generator created from -G. If the generator does not
support
platform specification in this way then -GP should be an error (all
generators except VS >= 8). If the generator does support -GP then
it
should do its own thing to save the value. For VS save it in a
cache
entry like "CMAKE_VS_PLATFORM" (we have "CMAKE_VS_PLATFORM_TOOLSET"
already for the VS 10 toolchain in some cases).
I'm not a big fan of your ideas: What about the parts where we
pass the generator platform to other parts? Do we want to add
branches for every generator type to get get correct value for
the -GP parameter (e.g. if (CMAKE_GENERATOR == "Visual Studio
...") "-GP ${CMAKE_VS_PLATFORM}")? IMHO that's not a good
idea. Also handling for making sure that generator platform
isn't changed by the user (like we do for -G already) in a
second run of CMake must be duplicated later if we add -GP to
more than one generator. (and so on...)
Good points, but we still need to reject -GP when using generators
for which it does not make sense. I think it may be moot anyway;
see below.
I realized that existing projects may test ${CMAKE_GENERATOR} to
look
for things like "Win64". For compatibility we need to make sure
that
-G "Visual Studio 10" -GP x64
results in CMAKE_GENERATOR being set to
-G "Visual Studio 10 Win64"
while processing CMake code even if it is not used that way
internally. Of course for future VS versions the generator names
will not need to work this way, only the existing ones.
Since we need to support -G "Visual Studio 10 Win64" anyway, I don't
see
much problem if such cases will work with -G "Visual Studio 10
Win64",
but not with -G "Visual Studio 10" -GP x64.
We are talking about changing the way the user selects the generator
in the GUI to be equivalent to -G/-GP. We cannot process existing
projects differently depending on how the generator was selected.
I also know there are projects that pass ${CMAKE_GENERATOR} to
internal invocations of CMake in order to say "build it like I'm
built". These paths would not work if any information moved over
to CMAKE_GENERATOR_PLATFORM or an equivalent variable.
I think the value of -GP has to be stored in CMAKE_GENERATOR at
the end of the generator name as it is now. The new option and GUI
updates are really just about simplifying the selection of the
generator and avoiding per-platform global generators in the internal
implementation. Users can either use -G and specify the full
generator name with platform or use -G/-GP separately but either way
the value of CMAKE_GENERATOR will be the same.
This can probably be improved in the future with a new cmake policy
but I don't want to open that can of worms just for WinCE. I think
you can implement -G/-GP such that the values are both stored in the
CMAKE_GENERATOR value. Internally we won't need a separate global
generator for every platform anymore, but that does not change the
public interface.
If we store everything in one variable (via string concatenation) I
don't see much value in an extra -GP switch. We need to split the
${CMAKE_GENERATOR} variable into generator+platform then all the time
anyway.
Maybe we can only change to current exact match of the generator name
to a "startsWith" and let the global generator class decide if the
generator name is valid?
-- Patrick
--
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
