Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

2014-11-09 Thread Stephen Kelly
On 11/07/2014 05:52 PM, Brad King wrote:
 On 11/07/2014 11:43 AM, Ben Boeckel wrote:
 IIUC that is to create a cmSourceFile entry for the object file
 corresponding to the source file.  They are different entries.
 Do we know the source file doesn't exist at this point? If so,
 CreateSourceFile would be better.
 My take: Normally it shouldn't because there should be exactly one
 object file per source file per target in a unique location.

 Steve?

The above reasoning makes sense to me, but I guess someone would have to
experiment with it.

 OTOH, it is possible that application code tries to set a
 property on an object file ahead of time.

Indeed.

Thanks,

Steve.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

2014-11-07 Thread David Cole via cmake-developers
I just looked at the diff, not the surrounding code, so forgive the
question if it's obvious when inspecting the code.. but here's a
question about your change before we push it into RC 2:

Is objectSources guaranteed to contain the same set of objects as mapping?

If so, I wonder why the code calls:
cmSourceFile* sf = context-Makefile-GetOrCreateSource(objFile, true);

instead of simply using map_it-first?

i.e. -- isn't the GetOrCreateSourceFile call superfluous if you have a
pointer to the source file object in the iterator...? Or is it a
const thing?


Curious,
David C.


On Thu, Nov 6, 2014 at 11:09 PM, clin...@elemtech.com wrote:

 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 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.gz
  cd netcdf-4.3.2
  mkdir build
  cd build
  cmake ../
  git init .
  git add .
  git commit -minit
  cmake ../
  git diff
 
 
  These files have modifications in them which will lead to relinking.
  liblib/CMakeFiles/netcdf.dir/build.make
  liblib/CMakeFiles/netcdf.dir/link.txt
 
  I see object files listed in a random order.  Perhaps there is a std::set
  used
  somewhere in CMake or something.
 
  I do not see this behavior with CMake 3.0.2.
 
  Clint
  --
 
  Powered by www.kitware.com
 
  Please keep messages on-topic and check the CMake FAQ at:
  http://www.cmake.org/Wiki/CMake_FAQ
 
  Kitware offers various services to support the CMake community. For more
  information on each offering, please visit:
 
  CMake Support: http://cmake.org/cmake/help/support.html
  CMake Consulting: http://cmake.org/cmake/help/consulting.html
  CMake Training Courses: http://cmake.org/cmake/help/training.html
 
  Visit other Kitware open-source projects at
  http://www.kitware.com/opensource/opensource.html
 
  Follow this link to subscribe/unsubscribe:
  http://public.kitware.com/mailman/listinfo/cmake-developers
 
 --

 Powered by www.kitware.com

 Please keep messages on-topic and check the CMake FAQ at: 
 http://www.cmake.org/Wiki/CMake_FAQ

 Kitware offers various services to support the CMake community. For more 
 information on each offering, please visit:

 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html

 Visit other Kitware open-source projects at 
 http://www.kitware.com/opensource/opensource.html

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

2014-11-07 Thread Brad King
On Thu, Nov 6, 2014 at 11:09 PM, Clinton Stimpson wrote:
 I've put in a fix for this.
 580b668d genex: Preserve order while evaluating TARGET_OBJECTS

Thanks.  I bisected it down to

 cmTarget: Allow any generator expression in SOURCES property.
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e5da9e51

where the problem was exposed by using the generator expression
to construct the list of sources.  However, the problematic code
was actually introduced at

 Genex: Evaluate TARGET_OBJECTS as a normal expression.
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf98cc25

Both of these were after 3.0 and before 3.1.

 Can we put this in RC 2?

Yes.  I added some comments, revised the commit message, and
merged to 'next' for testing:

 genex: Preserve order while evaluating TARGET_OBJECTS
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=caa4b7b8

On 11/07/2014 07:24 AM, David Cole via cmake-developers wrote:
 Is objectSources guaranteed to contain the same set of objects as mapping?

Yes.  Just above this context, mapping[] is populated by iterating over
objectSources.  Then ComputeObjectFilenames is called to fill in the
values of the map for each key.  It does not change the set of keys.

 isn't the GetOrCreateSourceFile call superfluous if you have a
 pointer to the source file object in the iterator...?

IIUC that is to create a cmSourceFile entry for the object file
corresponding to the source file.  They are different entries.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

2014-11-07 Thread Ben Boeckel
On Fri, Nov 07, 2014 at 09:51:39 -0500, Brad King wrote:
 On Thu, Nov 6, 2014 at 11:09 PM, Clinton Stimpson wrote:
  isn't the GetOrCreateSourceFile call superfluous if you have a
  pointer to the source file object in the iterator...?
 
 IIUC that is to create a cmSourceFile entry for the object file
 corresponding to the source file.  They are different entries.

Do we know the source file doesn't exist at this point? If so,
CreateSourceFile would be better.

--Ben
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

2014-11-07 Thread Brad King
On 11/07/2014 11:43 AM, Ben Boeckel wrote:
 IIUC that is to create a cmSourceFile entry for the object file
 corresponding to the source file.  They are different entries.
 
 Do we know the source file doesn't exist at this point? If so,
 CreateSourceFile would be better.

My take: Normally it shouldn't because there should be exactly one
object file per source file per target in a unique location.

Steve?

OTOH, it is possible that application code tries to set a
property on an object file ahead of time.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

2014-11-07 Thread Ben Boeckel
On Fri, Nov 07, 2014 at 11:52:45 -0500, Brad King wrote:
 OTOH, it is possible that application code tries to set a
 property on an object file ahead of time.

AFAIK, CMake doesn't expose where it stores these files and has always
treated it as an internal detail. Is this something we promise
compatibility on?

--Ben
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

2014-11-07 Thread Brad King
On 11/07/2014 12:19 PM, Ben Boeckel wrote:
 On Fri, Nov 07, 2014 at 11:52:45 -0500, Brad King wrote:
 OTOH, it is possible that application code tries to set a
 property on an object file ahead of time.
 
 AFAIK, CMake doesn't expose where it stores these files and has always
 treated it as an internal detail. Is this something we promise
 compatibility on?

No.  We just need to be sure we don't crash if they do try to
set one and happen to guess the location.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


[cmake-developers] CMake 3.1 regression with incremental builds ?

2014-11-06 Thread Clinton Stimpson

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.gz
cd netcdf-4.3.2
mkdir build
cd build
cmake ../
git init .
git add .
git commit -minit
cmake ../
git diff


These files have modifications in them which will lead to relinking.
liblib/CMakeFiles/netcdf.dir/build.make
liblib/CMakeFiles/netcdf.dir/link.txt

I see object files listed in a random order.  Perhaps there is a std::set used 
somewhere in CMake or something.

I do not see this behavior with CMake 3.0.2.

Clint
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

2014-11-06 Thread clinton
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 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.gz
 cd netcdf-4.3.2
 mkdir build
 cd build
 cmake ../
 git init .
 git add .
 git commit -minit
 cmake ../
 git diff
 
 
 These files have modifications in them which will lead to relinking.
 liblib/CMakeFiles/netcdf.dir/build.make
 liblib/CMakeFiles/netcdf.dir/link.txt
 
 I see object files listed in a random order.  Perhaps there is a std::set
 used
 somewhere in CMake or something.
 
 I do not see this behavior with CMake 3.0.2.
 
 Clint
 --
 
 Powered by www.kitware.com
 
 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ
 
 Kitware offers various services to support the CMake community. For more
 information on each offering, please visit:
 
 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html
 
 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html
 
 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake-developers
 
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers