On Thursday 14 March 2013, Brad King wrote:
On 03/13/2013 05:36 PM, Alexander Neundorf wrote:
On Wednesday 13 March 2013, Stephen Kelly wrote:
I think Alex' objection is only related to thinking that the case of a
header-only-library-with-automoc-generated-cxx-file should be an error.
On 03/14/2013 01:43 PM, Alexander Neundorf wrote:
Would you object a check that if a target has at least one C or Fortran
source
file, but no C++ source file, it should skipped for automoc ?
I was thinking about that approach too. Basically if the target
has at least one C++ source or *no
Brad King wrote:
On 03/14/2013 01:43 PM, Alexander Neundorf wrote:
Would you object a check that if a target has at least one C or Fortran
source file, but no C++ source file, it should skipped for automoc ?
I was thinking about that approach too. Basically if the target
has at least one
On Thursday 14 March 2013, Stephen Kelly wrote:
Brad King wrote:
On 03/14/2013 01:43 PM, Alexander Neundorf wrote:
Would you object a check that if a target has at least one C or Fortran
source file, but no C++ source file, it should skipped for automoc ?
I was thinking about that
Alexander Neundorf wrote:
yes, and I think it's a bug (caused by me).
If I was a cmake user and not a developer, I would file a bug report if I
would find out that my helloworld.c suddenly links again libstdc++.so
My point was that a policy is still needed anyway.
Thanks,
Steve.
--
Powered
Brad King wrote:
On 03/11/2013 07:01 PM, Stephen Kelly wrote:
Stephen Kelly wrote:
Alexander Neundorf wrote:
The patch only avoided that specific situation when it occured with
automoc, but the same situation can also happen independent from
automoc.
Not really, the attached case can only
On 03/12/2013 06:30 PM, Brad King wrote:
On 03/12/2013 06:08 PM, Alexander Neundorf wrote:
My AutomocFixWithoutQt branch basically reverts the first commit, so automoc
is now again only one step, without the temporary vector of targets, without
needing additional checks. In this form the
Brad King wrote:
On 03/12/2013 06:30 PM, Brad King wrote:
On 03/12/2013 06:08 PM, Alexander Neundorf wrote:
My AutomocFixWithoutQt branch basically reverts the first commit, so
automoc is now again only one step, without the temporary vector of
targets, without needing additional checks. In
On Wednesday 13 March 2013, Stephen Kelly wrote:
Brad King wrote:
...
Can you and Alex agree that fix-automoc-no-qt is sufficient for
the upcoming release?
I agree that it is sufficient.
I think Alex' objection is only related to thinking that the case of a
On 03/11/2013 07:01 PM, Stephen Kelly wrote:
Stephen Kelly wrote:
Alexander Neundorf wrote:
The patch only avoided that specific situation when it occured with
automoc, but the same situation can also happen independent from automoc.
Not really, the attached case can only crash because of
On Tuesday 12 March 2013, Brad King wrote:
On 03/11/2013 06:54 PM, Stephen Kelly wrote:
Alexander Neundorf wrote:
Unfortunately this patch creates bug (
http://public.kitware.com/Bug/view.php?id=13999 ) and doesn't fix the
actual problem, the crash is still there.
Before this patch,
On 03/12/2013 06:08 PM, Alexander Neundorf wrote:
The original use case in this thread has a header-only target whose
C++ linker language comes from the automoc source. This preserves
that functionality too.
I'm not sure this is functionality, and not actually a bug, see below.
It worked
Hi,
On Wednesday 20 February 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
On Wednesday 20 February 2013, Stephen Kelly wrote:
Brad King wrote:
Please fix and add this case to the tests.
I've added fix-automoc-linker-language to stage. Alex, could you review
please?
If
On Monday 11 March 2013, Alexander Neundorf wrote:
Hi,
...
(this is again the backtrace from the earlier, unmodified version).
I think instead of avoiding the case where the code crashes, it should not
crash.
I pushed the branch AutomocFixWithoutQt to stage.
It mostly reverts the previous
Alexander Neundorf wrote:
The patch only avoided that specific situation when it occured with
automoc, but the same situation can also happen independent from automoc.
Not really, the attached case can only crash because of the automoc support
built-in in cmake. Can you create a testcase
Stephen Kelly wrote:
Alexander Neundorf wrote:
The patch only avoided that specific situation when it occured with
automoc, but the same situation can also happen independent from automoc.
Not really, the attached case can only crash because of the automoc
support built-in in cmake. Can
Steve,
Please take a look at this example:
$ touch foo.h bar.cpp
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8.6)
project(FOO)
find_package(Qt4 REQUIRED)
add_library(bar STATIC bar.cpp)
set_target_properties(bar PROPERTIES AUTOMOC TRUE)
target_link_libraries(bar foo)
add_library(foo
Brad King wrote:
Please fix and add this case to the tests.
I've added fix-automoc-linker-language to stage. Alex, could you review
please?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please
On Wednesday 20 February 2013, Stephen Kelly wrote:
Brad King wrote:
Please fix and add this case to the tests.
I've added fix-automoc-linker-language to stage. Alex, could you review
please?
If I see it correctly, actually nothing is done to each target between the
calls to
Alexander Neundorf wrote:
On Wednesday 20 February 2013, Stephen Kelly wrote:
Brad King wrote:
Please fix and add this case to the tests.
I've added fix-automoc-linker-language to stage. Alex, could you review
please?
If I see it correctly, actually nothing is done to each target
20 matches
Mail list logo
