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
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,
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
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
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. :)
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13544
==
Reported By:Filip Konvicka (LOGIS)
Assigned To:
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
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
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
2012/9/17 Brad King brad.k...@kitware.com:
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
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:
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
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
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.
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
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
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.
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] Dakon ah, the VIPs are finally arriving ;)
[19:48:36] *** Modus #cmake +o Dakon durch ChanServ
[19:48:47] *** Modus #cmake +v davidcole durch
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
On Mon, Sep 17, 2012 at 4:35 PM, Alexander Neundorf neund...@kde.org 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
Hi,
sorry, I totally forgot about the IRC meeting.
On Monday 17 September 2012, Rolf Eike Beer wrote:
20:13:17] davidcole 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.
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
22 matches
Mail list logo
