Brad King wrote:
On 06/08/2012 12:59 PM, Stephen Kelly wrote:
Fixed now (I hope), thanks,
This change is now in master in preparation for 2.8.9.
Thanks for your work and persistence on this!
FYI, I rewrote the topic history prior to merging to clean up
all the cruft from dashboard fixes
On 06/08/2012 12:59 PM, Stephen Kelly wrote:
Fixed now (I hope), thanks,
This change is now in master in preparation for 2.8.9.
Thanks for your work and persistence on this!
FYI, I rewrote the topic history prior to merging to clean up
all the cruft from dashboard fixes and the change in
Brad King wrote:
On Wed, Jun 6, 2012 at 3:48 AM, Stephen Kelly
steve...@gmail.com wrote:
This seems to have caused todays failures:
http://open.cdash.org/buildSummary.php?buildid=2337242
* Does the test pass if you replace
if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
with
if(NOT
On 06/08/2012 04:50 AM, Stephen Kelly wrote:
I still have an error with Watcom that I don't know how to fix, which I
think is the last error on this topic:
http://open.cdash.org/testDetails.php?test=148809149build=2343558
My guess was that the CMAKE_CXX_COMPILE_OPTIONS_DLL flag is not
Brad King wrote:
On 06/08/2012 04:50 AM, Stephen Kelly wrote:
I still have an error with Watcom that I don't know how to fix, which I
think is the last error on this topic:
http://open.cdash.org/testDetails.php?test=148809149build=2343558
My guess was that the
On Fri, Jun 8, 2012 at 8:28 AM, Stephen Kelly steve...@gmail.com wrote:
Brad King wrote:
On 06/08/2012 04:50 AM, Stephen Kelly wrote:
I still have an error with Watcom that I don't know how to fix, which I
think is the last error on this topic:
David Cole wrote:
There's also this build warning:
http://open.cdash.org/viewBuildError.php?type=1buildid=2342611
Please eradicate that, and then this topic will be ready for merging.
Any idea what causes it?
I don't see why only that line would cause such a warning. It should be
On 06/08/2012 10:08 AM, Stephen Kelly wrote:
David Cole wrote:
There's also this build warning:
http://open.cdash.org/viewBuildError.php?type=1buildid=2342611
Please eradicate that, and then this topic will be ready for merging.
Any idea what causes it?
I don't see why only that
Brad King wrote:
On 06/08/2012 10:08 AM, Stephen Kelly wrote:
David Cole wrote:
There's also this build warning:
http://open.cdash.org/viewBuildError.php?type=1buildid=2342611
Please eradicate that, and then this topic will be ready for merging.
Any idea what causes it?
I don't
On 06/08/2012 11:16 AM, Stephen Kelly wrote:
David Cole wrote:
Please eradicate that, and then this topic will be ready for merging.
It looks like the unit test is not being executed on the FarAway linux
continuous build.
That started yesterday, and as it is continuous (unclean?), I
Brad King wrote:
On 06/08/2012 11:16 AM, Stephen Kelly wrote:
David Cole wrote:
Please eradicate that, and then this topic will be ready for merging.
It looks like the unit test is not being executed on the FarAway linux
continuous build.
That started yesterday, and as it is
On Fri, Jun 8, 2012 at 12:52 PM, Brad King brad.k...@kitware.com wrote:
On 06/08/2012 11:16 AM, Stephen Kelly wrote:
David Cole wrote:
Please eradicate that, and then this topic will be ready for merging.
It looks like the unit test is not being executed on the FarAway linux
Stephen Kelly wrote:
Brad King wrote:
On 06/05/2012 01:23 PM, Stephen Kelly wrote:
Brad King wrote:
You can't try_compile inside a platform file.
I'm not sure I'm trying to?
I thought you meant you would add the try_compile to the platform file
to decide whether to report -fPIE.
On Wed, Jun 6, 2012 at 3:48 AM, Stephen Kelly steve...@gmail.com wrote:
This seems to have caused todays failures:
http://open.cdash.org/buildSummary.php?buildid=2337242
* Does the test pass if you replace
if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 3.4)
with
if(NOT
On 06/05/2012 11:40 AM, Stephen Kelly wrote:
http://open.cdash.org/testDetails.php?test=148807497build=2335525
I tried outputting the OUTPUT resulting from the try_compile, but that does
not seem to actually create the output as expected, even though the
releveant commit is being tested
Brad King wrote:
On 06/05/2012 11:54 AM, Stephen Kelly wrote:
I can add a try_compile for -fPIE on APPLE (though I wonder if it would
work), but still, I expect to see something like that in the OUTPUT
variable from check_cxx_source_compiles...
The OUTPUT variable is internal to the macro
On 06/05/2012 01:23 PM, Stephen Kelly wrote:
Brad King wrote:
You can't try_compile inside a platform file.
I'm not sure I'm trying to?
I thought you meant you would add the try_compile to the platform file
to decide whether to report -fPIE.
Do you mean in the tests, or do you mean the
Brad King wrote:
On 06/05/2012 01:23 PM, Stephen Kelly wrote:
Brad King wrote:
You can't try_compile inside a platform file.
I'm not sure I'm trying to?
I thought you meant you would add the try_compile to the platform file
to decide whether to report -fPIE.
Do you mean in the tests,
Stephen Kelly wrote:
Brad King wrote:
The current implementation can be refactored in a way that
should make Xcode easy.
Then simply use the patch below for Xcode.
Great, thanks, all done.
I'll merge it into next next week when I can look at the dashboard.
I've merged it now.
Brad King wrote:
On 05/30/2012 02:22 PM, Stephen Kelly wrote:
Brad King wrote:
Also the code near calls to GetShouldUseOldFlags is not
indented with our convention.
I've had a look, and I don't see the breaks from the convention. Can you
say what commits and hunks?
In the makefile
On 05/31/2012 05:30 AM, Stephen Kelly wrote:
I see cmGlobalUnixMakefileGenerator3::AddCXXCompileCommand gave me the wrong
idea I think.
I never noticed that one, thanks.
and similarly in Ninja. The } else { construct is not consistent
with style in the rest of our code.
Both fixed.
See
On 05/30/2012 02:45 PM, Brad King wrote:
Thanks for your patience with so many rounds of review.
I think the topic is in good shape other than for Xcode.
I'll try to look at Xcode when I get a chance.
The current implementation can be refactored in a way that
should make Xcode easy. Instead
Brad King wrote:
The current implementation can be refactored in a way that
should make Xcode easy.
Then simply use the patch below for Xcode.
Great, thanks, all done.
I'll merge it into next next week when I can look at the dashboard.
Thanks,
Steve.
--
Powered by www.kitware.com
Brad King wrote:
On 05/29/2012 12:16 PM, Stephen Kelly wrote:
Done, though I left some notes in the commit for now. It seems the
existing variable is used for more than just PIC equivalents.
Thanks for going through all the platforms!
I think the only non-PIC instances are for Watcom and
On Wed, May 30, 2012 at 6:20 AM, Stephen Kelly steve...@gmail.com wrote:
RISCos.cmake and ULTRIX.cmake contains '-G 0' and HP-UX-HP.cmake contains
+Z. I don't know what they are really for.
HP's +Z option is for PIC:
What a mess. Sorry about that.
Updated now.
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
On 05/30/2012 12:26 PM, Stephen Kelly wrote:
What a mess. Sorry about that.
Updated now.
Great, that looks pretty good. A couple more comments:
The KWStyle test fails due to a few lines too long. Use:
$ git log master.. -p --pickaxe-regex -S.{80} -- Source
to look for hunks that add
Brad King wrote:
Also the code near calls to GetShouldUseOldFlags is not
indented with our convention.
I've had a look, and I don't see the breaks from the convention. Can you say
what commits and hunks?
I haven't tried to implement the XCode patch, but I removed the use from the
On 05/30/2012 02:22 PM, Stephen Kelly wrote:
Brad King wrote:
Also the code near calls to GetShouldUseOldFlags is not
indented with our convention.
I've had a look, and I don't see the breaks from the convention. Can you say
what commits and hunks?
In the makefile generator:
+if
Brad King wrote:
On 05/25/2012 04:47 PM, Stephen Kelly wrote:
I'm also not completely certain about the change to the try_compile
behavior in the branch. Could there be any reason to use
set(CMAKE_POSITION_INDEPENDENT_CODE ON) but want to do a try_compile
without -fPI{C,E} ? My guess is no,
On 05/29/2012 12:16 PM, Stephen Kelly wrote:
Done, though I left some notes in the commit for now. It seems the existing
variable is used for more than just PIC equivalents.
Thanks for going through all the platforms!
I think the only non-PIC instances are for Watcom and Embarcadero
where
On 05/25/2012 04:47 PM, Stephen Kelly wrote:
I'm also not completely certain about the change to the try_compile behavior
in the branch. Could there be any reason to use
set(CMAKE_POSITION_INDEPENDENT_CODE ON) but want to do a try_compile without
-fPI{C,E} ? My guess is no, because one
Hi,
I've re-pushed to my gitorious clone.
Brad King wrote:
On 05/17/2012 08:36 AM, Stephen Kelly wrote:
Done and re-pushed to my clone. I still have to write the unit tests, but
I think it can be reviewed again at this point.
Great start. Here are some comments.
The Update the
On 05/25/2012 04:47 PM, Stephen Kelly wrote:
I've re-pushed to my gitorious clone.
Thanks. I'll review when I get a chance.
AddPositionIndependentFlags shouldn't care whether the library is
shared or not, right?
My vague understanding up to now has been that static libraries should not
Brad King wrote:
On 05/25/2012 04:47 PM, Stephen Kelly wrote:
I've re-pushed to my gitorious clone.
Thanks. I'll review when I get a chance.
Something else that occured to me was that there's no way currently in the
branch to use both POSITION_INDEPENDENT_CODE and set FLAGS for all
On 05/17/2012 08:36 AM, Stephen Kelly wrote:
Done and re-pushed to my clone. I still have to write the unit tests, but I
think it can be reviewed again at this point.
Great start. Here are some comments.
The Update the documentation of IMPORTED_LOCATION to match the code. commit
has an
On 05/13/2012 04:24 PM, Stephen Kelly wrote:
I've added a 'WIP: Experiment with backwards compatibility.' patch to my
gitorious clone.
+ // TODO: Is there a 'not set' state for properties?
+ // We should handle that differently to boolean False.
There is a not set state for
On 5/5/2012 4:27 PM, Stephen Kelly wrote:
Ok. Then factoring out how it is set is the first step. Looking at the
output of 'git grep -i \?pic\b' and 'git grep -wi +Z', there are many
different ways of telling the compiler that we want this property. Most of
them are ancient unix which I can't
Stephen Kelly wrote:
Brad King wrote:
On 5/3/2012 12:02 PM, Stephen Kelly wrote:
* Make set(CMAKE_POSITION_INDEPENDENT_BINARIES True) set the appropriate
flags.
This is the right choice IMO, though the variable should just
initialize a POSITION_INDEPENDENT target property. The target
On 5/3/2012 12:02 PM, Stephen Kelly wrote:
* Make set(CMAKE_POSITION_INDEPENDENT_BINARIES True) set the appropriate flags.
This is the right choice IMO, though the variable should just
initialize a POSITION_INDEPENDENT target property. The target
property would then map to the right flag.
40 matches
Mail list logo
