I've put in a fix for this.
580b668d genex: Preserve order while evaluating TARGET_OBJECTS
Can we put this in RC 2?
Clint
- Original Message -
>
> Using the netcdf project
> ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4.3.2.tar.gz
>
> I see a problem with incremental builds doing a re
These are the earliest CDash results available for CMake:
http://open.cdash.org/index.php?project=CMake&date=2014-07-09
(they're discarded after 120 days...)
On Thu, Nov 6, 2014 at 5:27 PM, Rolf Eike Beer wrote:
> Am Donnerstag, 6. November 2014, 12:44:12 schrieb Brad King:
> > On 11/06/2014 12
Am Donnerstag, 6. November 2014, 12:44:12 schrieb Brad King:
> On 11/06/2014 12:00 PM, Chuck Atkins wrote:
> > I added an HP-UX block and adjusted the logic to be a bit more
> > consistent with the other "determine system" blocks
>
> Looks good to me, assuming the test for parisc on hpux is correc
Using the netcdf project
ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4.3.2.tar.gz
I see a problem with incremental builds doing a relink of libraries. Within
my project, this leads to unnecessarily relinking of many executables every
time I run cmake.
For example:
tar zxf netcdf-4.3.2.tar.g
On 11/06/2014 03:20 PM, Gregor Jasny wrote:
> As you can see in the patch the if command detects the continue
> invocation and aborts looping over the collected commands.
Right.
> IMHO what's needed is a in loop counter that counts how deep we are in a
> loop construct. It gets incremented within
On 04/11/14 21:21, Brad King wrote:
> On 11/04/2014 03:10 PM, Gregor Jasny wrote:
>> About the continue() outside of a block error: I added a test but I
>> have no idea how to enforce the desired behavior.
>
> It's been a while since I looked at the relevant parts of the code
> but here is one app
On 11/06/2014 12:00 PM, Chuck Atkins wrote:
> I added an HP-UX block and adjusted the logic to be a bit more
> consistent with the other "determine system" blocks
Looks good to me, assuming the test for parisc on hpux is correct.
-Brad
--
Powered by www.kitware.com
Please keep messages on-top
Rats! I keep forgetting about the bootstrap. I added an HP-UX block and
adjusted the logic to be a bit more consistent with the other "determine
system" blocks by moving the parisc determination out on it's own. How's
this?
# Determine whether this is HP-UX
if echo "${cmake_system}" | grep HP-U
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15235
==
Reported By:Andrew Aladjev
Assigned To:
On 11/06/2014 11:22 AM, Chuck Atkins wrote:
> The branch has been updated, merged, squashed, and remerged to next
Thanks. This hunk:
> # Determine whether this is Linux
> if echo "${cmake_system}" | grep Linux >/dev/null 2>&1; then
> cmake_system_linux=true
> # find out if it is a HP PA-RISC
>
> I hate MATCHES ;) at least make it MATCHES "^parisc".
>
A reasonable compromise.
The branch has been updated, merged, squashed, and remerged to next. We'll
see what happens tonight.
- Chuck
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://w
Am Donnerstag, 6. November 2014, 10:58:36 schrieben Sie:
> Aha! I'll change it to MATCHES instead of STREQUALS and that should do it
> since technically the issue is with both 32 and 64 bit architectures, it
> just might not have shown up yet on both. Perhaps the build name for the
> dashboard sh
Aha! I'll change it to MATCHES instead of STREQUALS and that should do it
since technically the issue is with both 32 and 64 bit architectures, it
just might not have shown up yet on both. Perhaps the build name for the
dashboard should be HPPA64 then instead HPPA32?
- Chuck
On Thu, Nov 6, 2014
Am Donnerstag, 6. November 2014, 10:37:25 schrieb Chuck Atkins:
> Hi Eike,
>
> So, it seems that voyager has no issue, only pioneer, which I'm just taking
> as coincidence from differences in various binary sizes. However, from
> looking at the error log, the link line for cmake shows:
>
> /usr/
Hi Eike,
So, it seems that voyager has no issue, only pioneer, which I'm just taking
as coincidence from differences in various binary sizes. However, from
looking at the error log, the link line for cmake shows:
/usr/bin/c++ -Wnon-virtual-dtor -Wcast-align -Wchar-subscripts -Wall -W
-Wshadow -W
On 06/11/14 14:25, Brad King wrote:
> Let's go with UPDATE_DISCONNECTED.
I renamed the option and the topic name and merged it to next for testing.
Thanks,
Daniele
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
K
On 11/06/2014 07:27 AM, David Cole wrote:
> I would prefer a name that begins with UPDATE_ if it only affects the update
> step.
>
> On Wed, Nov 5, 2014 at 6:57 PM, Daniele E. Domenichelli wrote:
>> SCM_DISCONNECTED or UPDATE_DISCONNECTED... Both work for me.
>>
>> Let me know if I should renam
I would prefer a name that begins with UPDATE_ if it only affects the
update step.
D
On Wed, Nov 5, 2014 at 6:57 PM, Daniele E. Domenichelli <
daniele.domeniche...@gmail.com> wrote:
> On 05/11/14 17:39, Brad King wrote:
> > Would the name "UPDATE_INDEPENDENT" or "UPDATE_DISCONNECTED"
> > make m
18 matches
Mail list logo
