headers
Philip Lowman | 1 Mar 2009 19:30

Re: Avoiding a relink

On Fri, Feb 27, 2009 at 5:24 PM, Brad King <brad.king-5opLkZggLXlBDgjK7y7TUQ@public.gmane.org> wrote:
Philip Lowman wrote:
I wasn't thinking of it in that context when I said that.  Yes, I think you're correct and I've noticed that behavior before.  I usually work around it with make foo/fast assuming foo is the shared library I'm patching.

Not sure why CMake does what it does.  For the Makefile generator (at least) it would seem that it would be fairly easy to avoid relinking against a shared library that has only had it's implementation changed.  A special file could be outputted alongside the ".so" that if present indicates that a header file changed and targets could depend on this instead of the shared library itself to handle relinking.

There must be some corner case neither of us can't think of.  Perhaps there is a way to break binary compatibility by modifying a cpp file? I can't think of any.

Try removing an object file from a shared library, rebuild just that library,
and then run the executable (which still exists).  It will break at runtime,
but if you try relinking the executable it will fail at build time and the
executable will not exist anymore.

Good point, although this could also be handled by forcing a relink against the .so when adding or removing files from add_library().
 
Also, it is possible that the executable's source files do manual extern
declarations instead of including header files.  Then the shared library
API can change and break the executable at runtime too.

You make a good point about the extern case.  Although I've never used this technique before I'm sure there is source code out here that does it.

So, is the idea worth logging as a feature request as an opt-in behavior?  It does seem like it would only be something CMake could easily control with the Makefile generator.  On the whole I could see this being very useful for projects that have lots of shared libraries or plugins, however.

--
Philip Lowman
_______________________________________________
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
Permalink | Reply | 1 comment |
headers
Alexander Neundorf | 1 Mar 2009 21:52
Picon

Re: Technique for generating projects that depend on generated sources

On Friday 27 February 2009, Steve Huston wrote:
> Thanks for the advice, Bill.
>
> My situation is somewhat different, though. The output source files
> are not known ahead of time. Thus, the general scheme is:
>
> - build runs the source generator; one of the outputs is a file
> containing the names of the generated sources.
> - rerun cmake to regenerate the build now that the complete list of
> sources is known.
> - rerun the build with the complete set of sources

Oh, this is ugly.
The purpose of cmake is to generate project files which contain information 
about which files need to be compiled and how. This happens at cmake time. 
Then these project files are read at build time and the files are built.
Now if the names of the files which should be built are not known at cmake 
time, cmake can't generate rules for them in the project files.

Can you run the source generator at cmake time ?
This would help against the problem. You can guard the generation e.g. with 
if(file1 NEWER_THAN file2)

Alex
_______________________________________________
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
Permalink | Reply | 4 comments |
headers
Alexander Neundorf | 1 Mar 2009 21:55
Picon

Re: Upper or lower case for package variables in FindXXX.cmake files?

On Friday 27 February 2009, Philip Lowman wrote:
> On Fri, Feb 27, 2009 at 1:13 PM, Matt Williams <lists@...> wrote:
...
> > There is no indication in the readme.txt which is preferred though I have
> > been
> > assuming the mixed case version. Based on bits and pieces I guess I am
> > right
> > (for example,the "DOXYGEN_FIND_QUIETLY, but it should have been
> > Doxygen_FIND_QUIETLY" comment in FindDoxygen.cmake).
>
> I have wondered the same thing for many a moon.
>
> The arguments to find_package, i.e. EXACT, QUIET, COMPONENTS, version
> number, etc. cause variables such as Doxygen_FIND_QUIETLY,
> Boost_COMPONENTS, and OpenSceneGraph_FIND_VERSION to be generated by CMake.
>  These are based directly off of the name of the find module filename so
> they will generally appear to be mixed case if that is the name of the
> module.
>
> Macros like FindPackageHandleStandardArgs seem to make everything upper
> case (i.e DOXYGEN_FOUND, OPENSCENEGRAPH_FOUND, etc.).
>
> Not sure what the answer is.  It's almost as if input variables are
> encouraged to be the case of the module and output variables are encouraged
> to be uppercase always.

Currently it is like this:
the variables which are set in a module, are all-upper case. The variables 
provided by cmake to the module, are exact-case.
The issue with changing the recommendation to use exact-case for everything is 
that most early cmake modules used all-upper-case, and so to stay consistent 
we should keep it like this for variables defined by modules.

Alex

_______________________________________________
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
Permalink | Reply | 1 comment |
headers
Alexander Neundorf | 1 Mar 2009 22:04
Picon

Re: ASM support

On Thursday 26 February 2009, Phil Smith wrote:
> I got back on this, and found a big part of my problem. The Wiki page says:
>
> "Edit CMakeASM_FOOInformation.cmake. ... then include the generic
> CMakeASMInformation.cmake." and later:
> "Edit CMakeDetermineASM_FOOCompiler.cmake. ...then include the generic
> file..."
>
> What wasn't obvious to me (though of course it is now) was that the second
> "generic file" wasn't the same as the first. If the Wiki page could say
> "...then include the generic file CMakeDetermineASMCompiler.cmake" it would
> help.
>
> ISTR that if you say INCLUDE(banana.cmake) it looks for it in the local
> directory, whereas INCLUDE(banana) looks for it in Modules. This could be
> made clearer too, as "include the generic CMakeASMInformation.cmake" is
> likely to result in the former.
>
> Now...CMake says it works, but "make" says:
>
> [ 11%] Building ASM_DIGNUS object CMakeFiles/zfpe.dir/temp/ZOSFINFO.asm.o
> make[2]: CMAKE_ASM_COMPILER: Command not found
> make[2]: *** [CMakeFiles/zfpe.dir/temp/ZOSFINFO.asm.o] Error 127
> make[1]: *** [CMakeFiles/zfpe.dir/all] Error 2
> make: *** [all] Error 2
>
> I thought the issue was related to using a front-end script for the
> assembler, such that the actual command (if typed on the commandline) to do
> an assembly would be "rexx.exe cc.rex dasm.exe" (with flags and operands
> after that), but I simplified it to just "dasm" and get the same error.
>
> My CMakeASM_DIGNUSInformation.cmake is:
>
> set(ASM_DIALECT _DIGNUS)
> include(CMakeASMInformation)
> set(ASM_DIALECT)
> SET(CMAKE_ASM_DIGNUS_SOURCE_FILE_EXTENSIONS asm)
> SET(CMAKE_ASM_DIGNUS_OUTPUT_EXTENSION ".o" )
> SET(CMAKE_ASM_DIGNUS_COMPILE_OBJECT "<CMAKE_ASM_COMPILER> -o <OBJECT>
> <SOURCE>")

I think this should be:

SET(CMAKE_ASM_DIGNUS_COMPILE_OBJECT "<CMAKE_ASM_DIGNUS_COMPILER> -o <OBJECT>
  <SOURCE>")

Alex
_______________________________________________
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
Permalink | Reply | 2 comments |
headers
Eric Noulard | 1 Mar 2009 22:15
Picon

Re: Technique for generating projects that depend on generated sources

2009/3/1 Alexander Neundorf <a.neundorf-work@...>:
> On Friday 27 February 2009, Steve Huston wrote:
>> Thanks for the advice, Bill.
>>
>> My situation is somewhat different, though. The output source files
>> are not known ahead of time. Thus, the general scheme is:
>>
>> - build runs the source generator; one of the outputs is a file
>> containing the names of the generated sources.
>> - rerun cmake to regenerate the build now that the complete list of
>> sources is known.
>> - rerun the build with the complete set of sources
>
> Oh, this is ugly.

I don't think that's much of ugly.
It's a classical "generated source" problem with the may be
not so common "I don't know the generated source file names".

I did use (in my pre-CMake era) re-entrant makefiles precisely for this
kind of issue.

> The purpose of cmake is to generate project files which contain information
> about which files need to be compiled and how. This happens at cmake time.
> Then these project files are read at build time and the files are built.
> Now if the names of the files which should be built are not known at cmake
> time, cmake can't generate rules for them in the project files.
>
> Can you run the source generator at cmake time ?

Yes you are right and I miss that,
if the generator is launched at CMake time it may help a lot.
Moreover I would say that the "source file list" generated by the generator
may be some kind of CMake file, let's say

generated_source.cmake

then one may

INCLUDE(generated_source.cmake OPTIONAL) in the CMakeLists.txt

then I CMake is clever enough:

0) during the first CMake run the optionnally included file is created
1) when launching the build after that the
    cmake_check_build_system  rule will notice that
    "generated_source.cmake" appeared and will automatically
    relaunch CMake and then
    the build.

Thus you would have the usual CMake + build step with an extra
CMake run triggered by the build step itself.

I've not tried so I may be wrong concerning the cleverness of a
INCLUDE(generated_source.cmake OPTIONAL)
statement.

> This would help against the problem. You can guard the generation e.g. with
> if(file1 NEWER_THAN file2)

I don't understand that point?

--

-- 
Erk
_______________________________________________
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
Permalink | Reply | 3 comments |
headers
Phil Smith | 1 Mar 2009 22:22

Re: ASM support

Yes, that was it. Thank you. I had hacked it into working by just setting CMAKE_ASM_COMPILER, but that was
clearly a hack.

One nit that I did have to work around: it doesn't seem to support operands on the compiler name, though in
trolling through code trying to understand what I'd done wrong, I saw things that looked like they might
have been trying to.

IOW, if I:

SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT "rexx.exe" "cc.rex dasm.exe")

then CMake works, but invokes rexx.exe without the "cc.rex dasm.exe" parameters. It happens that I can
work around this for my application, but since it works in a toolchain file:

SET(CMAKE_C_COMPILER   "rexx.exe" "cc.rex dcc.exe")
SET(CMAKE_CXX_COMPILER "rexx.exe" "cc.rex dcxx.exe")

it seems like it should here (for varying values of "should").

I'd offer some updates to http://www.kwwidgets.org/Wiki/CMake/Assembler to help others avoid my
idiocy if you're interested.

...phsiii
-----Original Message-----
From: Alexander Neundorf [mailto:a.neundorf-work@...]
Sent: Sunday, March 01, 2009 4:05 PM
To: cmake@...
Cc: Phil Smith
Subject: Re: [CMake] ASM support

On Thursday 26 February 2009, Phil Smith wrote:
> I got back on this, and found a big part of my problem. The Wiki page says:
>
> "Edit CMakeASM_FOOInformation.cmake. ... then include the generic
> CMakeASMInformation.cmake." and later:
> "Edit CMakeDetermineASM_FOOCompiler.cmake. ...then include the generic
> file..."
>
> What wasn't obvious to me (though of course it is now) was that the second
> "generic file" wasn't the same as the first. If the Wiki page could say
> "...then include the generic file CMakeDetermineASMCompiler.cmake" it would
> help.
>
> ISTR that if you say INCLUDE(banana.cmake) it looks for it in the local
> directory, whereas INCLUDE(banana) looks for it in Modules. This could be
> made clearer too, as "include the generic CMakeASMInformation.cmake" is
> likely to result in the former.
>
> Now...CMake says it works, but "make" says:
>
> [ 11%] Building ASM_DIGNUS object CMakeFiles/zfpe.dir/temp/ZOSFINFO.asm.o
> make[2]: CMAKE_ASM_COMPILER: Command not found
> make[2]: *** [CMakeFiles/zfpe.dir/temp/ZOSFINFO.asm.o] Error 127
> make[1]: *** [CMakeFiles/zfpe.dir/all] Error 2
> make: *** [all] Error 2
>
> I thought the issue was related to using a front-end script for the
> assembler, such that the actual command (if typed on the commandline) to do
> an assembly would be "rexx.exe cc.rex dasm.exe" (with flags and operands
> after that), but I simplified it to just "dasm" and get the same error.
>
> My CMakeASM_DIGNUSInformation.cmake is:
>
> set(ASM_DIALECT _DIGNUS)
> include(CMakeASMInformation)
> set(ASM_DIALECT)
> SET(CMAKE_ASM_DIGNUS_SOURCE_FILE_EXTENSIONS asm)
> SET(CMAKE_ASM_DIGNUS_OUTPUT_EXTENSION ".o" )
> SET(CMAKE_ASM_DIGNUS_COMPILE_OBJECT "<CMAKE_ASM_COMPILER> -o <OBJECT>
> <SOURCE>")

I think this should be:

SET(CMAKE_ASM_DIGNUS_COMPILE_OBJECT "<CMAKE_ASM_DIGNUS_COMPILER> -o <OBJECT>
  <SOURCE>")

Alex
_______________________________________________
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
Permalink | Reply | 1 comment |
headers
Gregory Sharp | 1 Mar 2009 22:34
Picon
Favicon

[CTest] DLLs, scripts, and build types


Hello,  I ran into a problem with getting the CTest to run when 
linking with a DLL.

1) My program links with ITK, and I build this as a DLL on windows.

2) During testing, my program needs to find the ITK dll.  I do not
wish to add to the global path.

3) My understanding is that the workaround for (2) is to create a 
script which sets the path.  So I make a CMake script.  CTest launches
the CMake script, which sets the path, and runs my executable.

4) However, my CMake script needs to know the name of the executable.
The executable can be in Release, or Debug, or whatever.  
Now I'm stuck, because I can't figure out how CMake can find the 
right directory.  There is a similar issue for finding the ITK dll, 
which can be in release or debug subdirectory.

I appreciate any advice.  Maybe there is a simple way?

Thank you,
--

-- 
Greg Sharp
gregsharp@...

      
_______________________________________________
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
Permalink | Reply | 3 comments |
headers
Alexander Neundorf | 1 Mar 2009 22:40
Picon

Re: Technique for generating projects that depend on generated sources

On Sunday 01 March 2009, you wrote:
> 2009/3/1 Alexander Neundorf <a.neundorf-work@...>:
> > On Friday 27 February 2009, Steve Huston wrote:
...
> > Can you run the source generator at cmake time ?
>
> Yes you are right and I miss that,
> if the generator is launched at CMake time it may help a lot.
> Moreover I would say that the "source file list" generated by the generator
> may be some kind of CMake file, let's say
>
> generated_source.cmake
>
> then one may
>
> INCLUDE(generated_source.cmake OPTIONAL) in the CMakeLists.txt
>
> then I CMake is clever enough:
>
> 0) during the first CMake run the optionnally included file is created
> 1) when launching the build after that the
>     cmake_check_build_system  rule will notice that
>     "generated_source.cmake" appeared and will automatically
>     relaunch CMake and then
>     the build.
> Thus you would have the usual CMake + build step with an extra
> CMake run triggered by the build step itself.
>
> I've not tried so I may be wrong concerning the cleverness of a
> INCLUDE(generated_source.cmake OPTIONAL) statement.

Just tried this, doesn't work. If the to-be-included file does not exist, no 
dependency to it is generated (wouldn't this actually result in a "no rule to 
make target foo" error ?).

> > This would help against the problem. You can guard the generation e.g.
> > with if(file1 NEWER_THAN file2)
>
> I don't understand that point?

This way it wouldn't be run at every cmake invocation but only if necessary.

Alex
_______________________________________________
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
Permalink | Reply | 0 comments |
headers
Alexander Neundorf | 1 Mar 2009 22:41
Picon

Re: ASM support

On Sunday 01 March 2009, Phil Smith wrote:
> Yes, that was it. Thank you. 

You're welcome :-)

...
> I'd offer some updates to http://www.kwwidgets.org/Wiki/CMake/Assembler to
> help others avoid my idiocy if you're interested.

Yes, please do so.

Alex
_______________________________________________
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
Permalink | Reply | 0 comments |
headers
Bill Hoffman | 1 Mar 2009 22:54
Favicon
Gravatar

Re: Technique for generating projects that depend on generated sources

I had another idea.  About how many generated files are there, and how 
big are they? It they are smallish, you could generate a single source 
file that includes the generated files.

generated.cxx
#include "gen1.cxx"
#include "gen2.cxx"
#include "gen3.cxx"
...

Then you could have a custom command generate gen1-N.cxx first, and then 
  generate generated.cxx last, and only compile generated.cxx.

-Bill

_______________________________________________
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
Permalink | Reply | 0 comments |

Gmane