Re: [CMake] Bug fix requests for the *next* release of CMake...

[Mike Wittman]

http://public.kitware.com/Bug/view.php?id=8438

-Mike

On 10/21/2011 01:20 PM, David Cole wrote:

As an esteemed colleague has pointed out, those with reporter level
account in Mantis may not edit bugs other than their own directly.
So. if you are in that boat, but would like to vote for a bug fix
to be considered for 2.8.7, please reply to this thread, and just list
the bug number, or a URL linking to its bug tracker page.

I will follow the replies to this thread and add those bugs to the
roadmap as they roll in.


Thanks,
David C.


On Fri, Oct 21, 2011 at 12:19 PM, David Coledavid.c...@kitware.com  wrote:

Hi all,

*NO* replies requested. Different technique this time. Please edit the
bug tracker directly. (Unless you have problems with the bug tracker:
if so, please feel free to reply here with your suggestions.)

We are planning for CMake 2.8.7, aiming for a December release. We're
targeting Dec. 28, 2011 for releasing it, and in order to make that
happen we'll have to do an rc1 by Dec. 7th or so... about 7 weeks
from now.

If you have a particular issue that you think should be fixed for
inclusion in 2.8.7, please put it on the roadmap yourself by the end
of next week, Fri. Oct. 28th. To do so, edit the bug at
http://public.kitware.com/Bug and set the Target Version field to
CMake 2.8.7 - that will make it appear on the roadmap page (
http://www.cmake.org/Bug/roadmap_page.php?version_id=89 ). Also: add a
note saying why it's important to you, or even add a patch that fixes
and documents and tests it if you're able to.

Ideally, each issue will be discussed as needed on the mailing list to
come to any consensus about what should be done to fix it, and then
the entry in the bug tracker may be used to keep it on the radar
screen, and to track activity related to it.

Patches are *always* welcome. Patches that include testing of any new
features, or tests that prove a bug is really fixed on the dashboards
are better: a patch with testing is strongly preferred over a patch
with no testing. Also, if you are *adding* code, then you also
probably need to add *tests* of that code, so that the coverage
percentage stays as is or rises.

Please discuss issues here on the mailing list as needed, and add
notes to existing issues in the bug tracker that you are interested in
seeing fixed for 2.8.7 -- we will be looking at activity both on the
mailing list and in the bug tracker to help prioritize the bug fixes
for the next couple months.


Thanks,
David Cole
Kitware, Inc.


P.S. - as a nice summary of what we accomplished in the CMake 2.8.6
release, including contributions from 27 individuals around the world,
see here: http://public.kitware.com/Bug/changelog_page.php?version_id=87
-- it currently lists 43 issues that we resolved: nice job, everybody!

(Many of those were specifically addressed because somebody brought it
up in response to my similar email from just after 2.8.5... Don't be
shy!)


--

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 this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


--

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 this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Adding a custom line to CMake's makefiles?

[Mike Wittman]

If you are building on Linux, try
MAKEFLAGS=j8 make distcheck

I have successfully used the MAKEFLAGS environment variable to propagate 
parallel build invocations through scripts that invoke make with fixed 
options.


-Mike

On 09/09/2011 09:21 AM, Clifford Yapp wrote:
I can finally give a good concrete case where I might need to do this 
(or need some other very clever solution).


I have created a distcheck command for BRL-CAD that has a lot of 
responsibilities, including doing a complete configure and build of 
BRL-CAD from a source archive expanded from a CPack tarball.  The 
distcheck rule uses cmake to fire off the build (this is to try and be 
future proof against using other tools than Make to do a distcheck) 
but I need to pass the parallel build setting -j from Make down to the 
${CMAKE_COMMAND} build launched by the distcheck rule, and there 
doesn't seem to be any way to do it.


This is the subset of the distcheck rule (somewhat edited for clarity):

   ADD_CUSTOM_TARGET(distcheck
  COMMAND ${CMAKE_COMMAND} -E echo Stage 1:  Create source tgz, 
tbz2 and zip archives from toplevel archive.
  COMMAND cpack --config 
${CMAKE_CURRENT_BINARY_DIR}/CPackSourceConfig.cmake
  COMMAND ${CMAKE_COMMAND} -E echo Stage 2:  Expand tgz archive 
and prepare to build from archive sources.
  COMMAND ${CMAKE_COMMAND} -E tar xvzf 
${CPACK_SOURCE_PACKAGE_FILE_NAME}.tar.gz
  COMMAND ${CMAKE_COMMAND} -E make_directory 
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-build
  COMMAND ${CMAKE_COMMAND} -E make_directory 
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-install
  COMMAND ${CMAKE_COMMAND} -E chdir 
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-build ${CMAKE_COMMAND} 
../${CPACK_SOURCE_PACKAGE_FILE_NAME} 
-DCMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/_${CPACK_SOURCE_PACKAGE_FILE_NAME}-install
  COMMAND ${CMAKE_COMMAND} -E echo Stage 3:  Compile using source 
from tgz archive.
  COMMAND ${CMAKE_COMMAND} --build 
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-build

  )

This can be successfully fired off by make distcheck, which is the 
desired behavior.  However, the --build option doesn't respect 
(naturally) any -jN options fed to make, since they aren't specified 
at CMake time when the distcheck Makefile target is being generated.


Perversely enough, if I'm understanding the issue correctly I won't be 
able to use the -jN value itself in any case, even if the Makefile can 
be taught to do something smart: 
http://old.nabble.com/MAKEFLAGS-var-does-not-show-%22-j%22-param-td15983337.html


The best idea I can come up with so far is for the CMake generated 
Makefile to write out a variable containing some CPU related variable 
(e.g. make CPUS=8 and write the value of $(CPUS) to 
CMakeFiles/make_cpu_flag or some such) and then convert the distcheck 
commands above into a series of EXECUTE_PROCESS lines in a 
rundistcheck.cmake file that is launched by the distcheck rule with a 
${CMAKE_COMMAND}.  In rundistcheck.cmake, I can check for the presence 
of the make_cpu_flag file and if found add the -j parallel flag to the 
--build line before running it.  That will mean a parallel distcheck 
will have to use a different make syntax than the standard make -j, 
but at least it would be something.  Unfortunately, that means I still 
need the Makefile to let me know what was passed in up front, which 
means tweaking the CMake generated output somehow (not really sure how 
yet).


Does anybody else have a mechanism for passing parallel build 
instructions from make down to child ${CMAKE_COMMAND} --build instances?


Cheers,
CY


On Wed, Feb 2, 2011 at 4:32 PM, Michael Hertling mhertl...@online.de 
mailto:mhertl...@online.de wrote:


On 02/02/2011 03:34 PM, Clifford Yapp wrote:
 Is there any way to customize the Makefile output from CMake to
 include user-defined lines (say, something like #include
 Makefile.inc) at the end of each Make file?


 [snip]

However, this approach is neither portable nor clean
nor your-expectation-here, so I would ask Eric's questions, too. ;)

Regards,

Michael



___
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 this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


___
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 this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Adding a custom line to CMake's makefiles?

[Mike Wittman]

Yes, but only when setting MAKEFLAGS from within a Makefile.  It appears 
the rules do not apply when MAKEFLAGS is set by the invoking shell.  
(And actually, current GNU make handles parallel execution differently 
on Linux, using a job server that all make subprocesses use to 
coordinate execution -- the documentation below is from 1998.)


If you still don't believe :)  try putting the following in a Makefile 
and running MAKEFLAGS=j3 make


all: r1 r2 r3
r1 r2 r3:
echo rule $@; sleep 5

-Mike

On 09/09/2011 02:55 PM, Jean-Christophe Fillion-Robin wrote:
Reading through make documentation, seems setting -jx to MAKEFLAGS is 
a no-op.


/The `-j' option is a special case (see section Parallel Execution 
http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_47.html#SEC46). 
If you set it to some numeric value, `-j 1' is always put into 
|MAKEFLAGS| instead of the value you specified. This is because if the 
`-j' option were passed down to sub-|make|s, you would get many more 
jobs running in parallel than you asked for. If you give `-j' with no 
numeric argument, meaning to run as many jobs as possible in parallel, 
this is passed down, since multiple infinities are no more than one. /


Source: http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_53.html

Jc

On Fri, Sep 9, 2011 at 3:37 PM, Mike Wittman 
michael.witt...@headwave.com mailto:michael.witt...@headwave.com 
wrote:


If you are building on Linux, try
MAKEFLAGS=j8 make distcheck

I have successfully used the MAKEFLAGS environment variable to
propagate parallel build invocations through scripts that invoke
make with fixed options.

-Mike


On 09/09/2011 09:21 AM, Clifford Yapp wrote:

I can finally give a good concrete case where I might need to do
this (or need some other very clever solution).

I have created a distcheck command for BRL-CAD that has a lot of
responsibilities, including doing a complete configure and build
of BRL-CAD from a source archive expanded from a CPack tarball. 
The distcheck rule uses cmake to fire off the build (this is to

try and be future proof against using other tools than Make to do
a distcheck) but I need to pass the parallel build setting -j
from Make down to the ${CMAKE_COMMAND} build launched by the
distcheck rule, and there doesn't seem to be any way to do it.

This is the subset of the distcheck rule (somewhat edited for
clarity):

   ADD_CUSTOM_TARGET(distcheck
  COMMAND ${CMAKE_COMMAND} -E echo Stage 1:  Create source
tgz, tbz2 and zip archives from toplevel archive.
  COMMAND cpack --config
${CMAKE_CURRENT_BINARY_DIR}/CPackSourceConfig.cmake
  COMMAND ${CMAKE_COMMAND} -E echo Stage 2:  Expand tgz
archive and prepare to build from archive sources.
  COMMAND ${CMAKE_COMMAND} -E tar xvzf
${CPACK_SOURCE_PACKAGE_FILE_NAME}.tar.gz
  COMMAND ${CMAKE_COMMAND} -E make_directory
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-build
  COMMAND ${CMAKE_COMMAND} -E make_directory
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-install
  COMMAND ${CMAKE_COMMAND} -E chdir
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-build ${CMAKE_COMMAND}
../${CPACK_SOURCE_PACKAGE_FILE_NAME}

-DCMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/_${CPACK_SOURCE_PACKAGE_FILE_NAME}-install
  COMMAND ${CMAKE_COMMAND} -E echo Stage 3:  Compile using
source from tgz archive.
  COMMAND ${CMAKE_COMMAND} --build
_${CPACK_SOURCE_PACKAGE_FILE_NAME}-build
  )

This can be successfully fired off by make distcheck, which is
the desired behavior.  However, the --build option doesn't
respect (naturally) any -jN options fed to make, since they
aren't specified at CMake time when the distcheck Makefile target
is being generated.

Perversely enough, if I'm understanding the issue correctly I
won't be able to use the -jN value itself in any case, even if
the Makefile can be taught to do something smart:

http://old.nabble.com/MAKEFLAGS-var-does-not-show-%22-j%22-param-td15983337.html

The best idea I can come up with so far is for the CMake
generated Makefile to write out a variable containing some CPU
related variable (e.g. make CPUS=8 and write the value of $(CPUS)
to CMakeFiles/make_cpu_flag or some such) and then convert the
distcheck commands above into a series of EXECUTE_PROCESS lines
in a rundistcheck.cmake file that is launched by the distcheck
rule with a ${CMAKE_COMMAND}.  In rundistcheck.cmake, I can check
for the presence of the make_cpu_flag file and if found add the
-j parallel flag to the --build line before running it.  That
will mean a parallel distcheck will have to use a different make
syntax than the standard make -j, but at least it would be
something.  Unfortunately, that means I still need the Makefile
to let me know what was passed in up front, which means

Re: [CMake] [cmake-developers] Bug fix requests for the *next* release of CMake...

[Mike Wittman]

I'll third that.  I'd like to see 8438 addressed as well.

-Mike

On 03/29/2011 02:56 PM, Tyler wrote:
 Eric, those all look good, but I'd like to particularly +1 this one:

 http://public.kitware.com/Bug/view.php?id=8438

 I've hacked around this deficiency in several places and I'm sure
 other users have as well. It would be nice to replace these hacks with
 a nice simple solution.

 Thanks,
 tyler

 On Tue, Mar 29, 2011 at 12:38 PM, Eric Noulard eric.noul...@gmail.com wrote:
   
 2011/3/29 David Cole david.c...@kitware.com:
 
 Please discuss issues here as needed, and add notes to existing issues in
 the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will
 be looking at the mailing list and activity in the bug tracker to help
 prioritize the bug fixes that will occur over the next 4 weeks.
   
 http://public.kitware.com/Bug/view.php?id=8438
 http://public.kitware.com/Bug/view.php?id=10067
 http://public.kitware.com/Bug/view.php?id=11656
 http://public.kitware.com/Bug/view.php?id=11944

 I'll try to work on the last 3 but any help for those will be appreciated.

 --
 Erk
 Membre de l'April - « promouvoir et défendre le logiciel libre » -
 http://www.april.org
 ___
 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 this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/listinfo/cmake

 
 ___
 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 this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/listinfo/cmake
   

___
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 this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake