Re: [CMake] Obtaining improved GNU make performance on Makefiles generated by cmake

[Bill Hoffman]

Alan W. Irwin wrote:

The GNU make documentation states the following:

   Since it knows that phony targets do not name actual files that
   could be remade from other files, make skips the implicit rule search
   for phony targets This is why declaring a
   target phony is good for [make] performance

Also,

   Using .PHONY' is more explicit and more efficient.  However, other
   versions of make' do not support .PHONY'; thus FORCE (an arbitrarily
   named rule with no prerequisites or rules) appears in
   many makefiles.

As part of another investigation I searched a Linux build tree created by
cmake (2.4.8) and was surprised to find no reference to .PHONY. Instead, 
the makefile generator on Linux is using the same method as FORCE idea

above, i.e., a rule called cmake_force with no prerequisites or commands to
serve as a prerequisite to rules that must be run every time.

CMake is missing a bet on Linux systems to reduce Makefile overhead 
since it

is using this cmake_force approach rather than the preferred more
efficient.PHONY approach for rules that must be run every time.  Since the
Makefiles generated by cmake have an extremely large number of such rules,
Makefile latency may be significantly reduced by this method on Linux (GNU
make) systems.

If the cmake developers here like this idea (or at least don't strongly
dislike it), I will go ahead and make a feature request so it doesn't get
lost.



CMake is written to generic make, and I don't think we would want to add 
something that only worked with gmake.  The trouble is the make you are 
using can change after CMake is run, so we can not even test for the 
version of make being used.   I guess if it was a big enough performance 
gain, we could add some sort of option to allow for this.  However, I 
would want to make sure that there would be a good payback.  So far the 
cmake makefiles outperform the autotools ones quite well, and 
performance has not been an issue.   Do you think you are having a 
performance problem?


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] embed version numbers in libraries (.so, a) and executables

[Ittay Dror]

Hi,

Does cmake have support for embedding version numbers in libraries and 
executables? Specifically:
* generate a string with the library / executable name, containing the 
version

* allow nightly builds to add build number
* add checksum (sha1) to uniquely identify a the library / executable 
based on its source files and compilation flags


If there isn't such a thing, could you point me to information on how to 
get started creating such a module?


Thank you,
Ittay

--
Ittay Dror <[EMAIL PROTECTED]>
Tikal 
Tikal Project 

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Obtaining improved GNU make performance on Makefiles generated by cmake

[Alan W. Irwin]

The GNU make documentation states the following:

   Since it knows that phony targets do not name actual files that
   could be remade from other files, make skips the implicit rule search
   for phony targets This is why declaring a
   target phony is good for [make] performance

Also,

   Using .PHONY' is more explicit and more efficient.  However, other
   versions of make' do not support .PHONY'; thus FORCE (an arbitrarily
   named rule with no prerequisites or rules) appears in
   many makefiles.

As part of another investigation I searched a Linux build tree created by
cmake (2.4.8) and was surprised to find no reference to .PHONY. Instead, 
the makefile generator on Linux is using the same method as FORCE idea

above, i.e., a rule called cmake_force with no prerequisites or commands to
serve as a prerequisite to rules that must be run every time.

CMake is missing a bet on Linux systems to reduce Makefile overhead since it
is using this cmake_force approach rather than the preferred more
efficient.PHONY approach for rules that must be run every time.  Since the
Makefiles generated by cmake have an extremely large number of such rules,
Makefile latency may be significantly reduced by this method on Linux (GNU
make) systems.

If the cmake developers here like this idea (or at least don't strongly
dislike it), I will go ahead and make a feature request so it doesn't get
lost.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake on open solaris

[Matthew Woehlke]

Bill Hoffman wrote:

Matthew Woehlke wrote:

Tavitayya Varanasi wrote:
SUN is planing to port cmake on Indiana ( a version of open 
solaris ).


There is porting to be done? Hmm... I successfully built and tested 
cmake 2.4.8 on Solaris 10/x86... I admit I haven't actually *used* 
that build, though I have used 2.4.6 on a different Sun box. I want to 
say that's the platform where ctest+gmake have some strange 
interaction that makes two of the tests fail *only* when run under 
gmake, but other than that, as far as I know everything works "out of 
the box". (Incidentally, if you can get one of GNU or Kitware to take 
responsibility for the problem and actually fix it, that would be 
great; I had no success when I tried.)




If someone is willing to setup a nightly dashboard on a system we do not 
have nightly testing for, I will help them get all tests passing.  If 
not, it is a waste of my time, since it will likely be broken again in 
the future without nightly testing.


Alas, unless I get the opportunity to start a new project (in which case 
I will be strongly pushing cmake as the build system), I doubt I'd be 
able to get permission to set up nightly tests. Which is too bad, 
because if I *could* convince a project to switch, and subsequently 
convince people that nightly tests of the build tool are a Good Idea, 
I'd stand a chance at contributing nightly builds for about a dozen 
platforms.


However, as I was saying, the problem is not the tests themselves, but 
the tests /run under GNU make/, i.e. they pass when I invoke ctest 
directly. I tried to take this up with the GNU make folk, but I got one 
response, and none to my follow-up. Here's the link to the latest I had:

http://lists.gnu.org/archive/html/bug-make/2007-03/msg00037.html

--
Matthew
Sending this e-mail does not constitute endorsement of the contents; I 
may change my mind later. -- Unknown


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake on open solaris

[Bill Hoffman]

Matthew Woehlke wrote:

Tavitayya Varanasi wrote:
SUN is planing to port cmake on Indiana ( a version of open 
solaris ).


There is porting to be done? Hmm... I successfully built and tested 
cmake 2.4.8 on Solaris 10/x86... I admit I haven't actually *used* that 
build, though I have used 2.4.6 on a different Sun box. I want to say 
that's the platform where ctest+gmake have some strange interaction that 
makes two of the tests fail *only* when run under gmake, but other than 
that, as far as I know everything works "out of the box". (Incidentally, 
if you can get one of GNU or Kitware to take responsibility for the 
problem and actually fix it, that would be great; I had no success when 
I tried.)




If someone is willing to setup a nightly dashboard on a system we do not 
have nightly testing for, I will help them get all tests passing.  If 
not, it is a waste of my time, since it will likely be broken again in 
the future without nightly testing.



-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake on open solaris

[Matthew Woehlke]

Tavitayya Varanasi wrote:
SUN is planing to port cmake on Indiana ( a version of open solaris 
).


There is porting to be done? Hmm... I successfully built and tested 
cmake 2.4.8 on Solaris 10/x86... I admit I haven't actually *used* that 
build, though I have used 2.4.6 on a different Sun box. I want to say 
that's the platform where ctest+gmake have some strange interaction that 
makes two of the tests fail *only* when run under gmake, but other than 
that, as far as I know everything works "out of the box". (Incidentally, 
if you can get one of GNU or Kitware to take responsibility for the 
problem and actually fix it, that would be great; I had no success when 
I tried.)



Is this a right alias to post some doubts if we have?


You doubt cmake? ;-)

If you mean "questions", then yes.

--
Matthew
Sending this e-mail does not constitute endorsement of the contents; I 
may change my mind later. -- Unknown


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Batch converting several files

[Andy Lego]

Hello Martin,

You are missing a ( after the ADD_CUSTOM_COMMAND.

Andy

On Mon, Mar 17, 2008 at 2:18 PM, Martin Fischer <[EMAIL PROTECTED]> wrote:
> Hi Andy,
>
>  it seems I don't understand the direction you are pointing me to.  I
>  used add_custom_command in some occasions. So now I tried:
>
>  FOREACH( FILE ${SOURCEFILES})
>   ADD_CUSTOM_COMMAND ${FILE}.out
>   COMMAND ${tool_EXE} ${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.in
>
> ${CMAKE_CURRENT_BINARY_DIR}/${FILE}.out
>  DEPEND tool ${FILE}.in
> )
>  ENDFOREACH( FILE )
>
>  CMake outputs: "Wrong syntax. Unknown type of argument"
>
>  It looks like I'll go the less flexible way to code a list of commands
>  to execute.
>
>  Frustrated
>  Martin
>
>
>
>
>
>  On 17.03.2008 01:44 Andy Lego wrote:
>  > Hi Martin,
>  >
>  > When you add things to the custom target they will be executed in one
>  > step. What you want are custom commands. Look at the manual for
>  > add_custom_command.
>  >
>  > Andy
>  >
>  > On Sun, Mar 16, 2008 at 8:31 AM, Martin Fischer <[EMAIL PROTECTED]> wrote:
>  >> On 11.03.2008 21:24 Andy Lego wrote:
>  >>
>  >>  Hi Andy,
>  >>
>  >>  so I tried the following
>  >>
>  >>  SET( SOURCEFILES
>  >>   file1
>  >>   file2
>  >>   file3 )
>  >>
>  >>
>  >>  FOREACH( FILE ${SOURCEFILES})
>  >> SET( EXECUTE
>  >>  ${EXECUTE}
>  >>  ${tool_EXE} ${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.in
>  >>  ${CMAKE_CURRENT_BINARY_DIR}/${FILE}.out )
>  >>  ENDFOREACH( FILE )
>  >>
>  >>
>  >>  ADD_CUSTOM_TARGET( carfiles
>  >>DEPENDS SOURCEFILES tool
>  >>COMMAND ${EXECUTE}
>  >>   )
>  >>
>  >>  It looks like the variable EXCUTE is initialized as expected but is
>  >>  considered as one command and not a sequence. Where am I going wrong?
>  >>
>  >>  Regards
>  >>  Martin
>  >>
>  >>
>  >>  > Hello Martin,
>  >>  >
>  >>  > You cannot nest commands and constructs. Move the FOREACH before the
>  >>  > custom target and set a variable in it. Then use the result in the
>  >>  > custom target.
>  >>  >
>  >>  > Andy
>  >>  >
>  >>
>  >>> On Tue, Mar 11, 2008 at 12:44 PM, Martin Fischer <[EMAIL PROTECTED]> 
> wrote:
>  >>  >> > Hi,
>  >>  >> >
>  >>  >> >  for a project I'm working on I need to do the following build 
> steps:
>  >>  >> >
>  >>  >> >  - compile an executable from source
>  >>  >> >  - run this executable to convert several files
>  >>  >> >  - for each input file in source directory there will be one output 
> file
>  >>  >> >  in build directory.
>  >>  >> >
>  >>  >> >  I tried several variants of he following but didn't come up with a 
> good
>  >>  >> >  solution.
>
>
>



-- 
http://legoandy.com -o- http://capitalmtb.org

Support my 150 mile bike ride to fight MS:
http://bikecan.nationalmssociety.org/site/TR?px=3921627&pg=personal&fr_id=9066
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Batch converting several files

[Martin Fischer]

Hi Andy,

it seems I don't understand the direction you are pointing me to.  I 
used add_custom_command in some occasions. So now I tried:


FOREACH( FILE ${SOURCEFILES})
 ADD_CUSTOM_COMMAND ${FILE}.out
 COMMAND ${tool_EXE} ${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.in 
${CMAKE_CURRENT_BINARY_DIR}/${FILE}.out

 DEPEND tool ${FILE}.in
   )
ENDFOREACH( FILE )

CMake outputs: "Wrong syntax. Unknown type of argument"

It looks like I'll go the less flexible way to code a list of commands 
to execute.


Frustrated
Martin



On 17.03.2008 01:44 Andy Lego wrote:

Hi Martin,

When you add things to the custom target they will be executed in one
step. What you want are custom commands. Look at the manual for
add_custom_command.

Andy

On Sun, Mar 16, 2008 at 8:31 AM, Martin Fischer <[EMAIL PROTECTED]> wrote:

On 11.03.2008 21:24 Andy Lego wrote:

 Hi Andy,

 so I tried the following

 SET( SOURCEFILES
  file1
  file2
  file3 )


 FOREACH( FILE ${SOURCEFILES})
SET( EXECUTE
 ${EXECUTE}
 ${tool_EXE} ${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.in
 ${CMAKE_CURRENT_BINARY_DIR}/${FILE}.out )
 ENDFOREACH( FILE )


 ADD_CUSTOM_TARGET( carfiles
   DEPENDS SOURCEFILES tool
   COMMAND ${EXECUTE}
  )

 It looks like the variable EXCUTE is initialized as expected but is
 considered as one command and not a sequence. Where am I going wrong?

 Regards
 Martin


 > Hello Martin,
 >
 > You cannot nest commands and constructs. Move the FOREACH before the
 > custom target and set a variable in it. Then use the result in the
 > custom target.
 >
 > Andy
 >


On Tue, Mar 11, 2008 at 12:44 PM, Martin Fischer <[EMAIL PROTECTED]> wrote:

 >> > Hi,
 >> >
 >> >  for a project I'm working on I need to do the following build steps:
 >> >
 >> >  - compile an executable from source
 >> >  - run this executable to convert several files
 >> >  - for each input file in source directory there will be one output file
 >> >  in build directory.
 >> >
 >> >  I tried several variants of he following but didn't come up with a good
 >> >  solution.



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] per target flags

[Alexander Neundorf]

On Monday 17 March 2008, Egon Kocjan wrote:
> On Mon, 2008-03-17 at 02:21 +0100, Pau Garcia i Quiles wrote:
> > Quoting Egon Kocjan <[EMAIL PROTECTED]>:
> > > Are/will-be there per target commands for adding include directories
> > > and preproc. defines?
> >
> > SET_DIRECTORY_PROPERTIES
> > SET_SOURCE_FILES_PROPERTIES
> > SET_TARGET_PROPERTIES
> >
> > You may also want to take a look at this page:
> > http://www.cmake.org/Wiki/CMake_Useful_Variables
>
> Yes, I did RTFM before asking, I came up with this:
> GET_TARGET_PROPERTY(_TMP TGT COMPILE_FLAGS)
> SET_TARGET_PROPERTIES(TGT PROPERTIES COMPILE_FLAGS "${_TMP} -Isome_dir
> -Dsomething=3")
>
> But this seems wrong to me, I assumed there's a better way. Like:
>
> TARGET_ADD_INCLUDES(TGT some_dir1 some_dir2)

There will probably be SET_TARGET_PROPERTIES(... INCLUDE_DIRS ...) at some 
point in the not too distant future.

Alex

P.S. patches may help :-)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] per target flags

[Egon Kocjan]

On Mon, 2008-03-17 at 02:21 +0100, Pau Garcia i Quiles wrote:
> Quoting Egon Kocjan <[EMAIL PROTECTED]>:
> 
> > Are/will-be there per target commands for adding include directories and
> > preproc. defines?
> 
> SET_DIRECTORY_PROPERTIES
> SET_SOURCE_FILES_PROPERTIES
> SET_TARGET_PROPERTIES
> 
> You may also want to take a look at this page:
> http://www.cmake.org/Wiki/CMake_Useful_Variables

Yes, I did RTFM before asking, I came up with this:
GET_TARGET_PROPERTY(_TMP TGT COMPILE_FLAGS)
SET_TARGET_PROPERTIES(TGT PROPERTIES COMPILE_FLAGS "${_TMP} -Isome_dir
-Dsomething=3")

But this seems wrong to me, I assumed there's a better way. Like:

TARGET_ADD_INCLUDES(TGT some_dir1 some_dir2)


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake