Re: [CMake] Library dependency
On 8/10/07, Kyle Heath <[EMAIL PROTECTED]> wrote: > I would like to use cmake to build a set of single target projects > (each project generates either one library or one executable). I > understand how to handle dependencies on external packages with the > Find.cmake scripts, but I don't know how to deal with internal > CMake built packages. There is some kind of magic with a > Config.cmake that I don't understand. > > Here's a little high-level "use case" scenario to illustrate what I want to > do: > > My executable project HelloWorld uses package "MyLibA" directly. In > the CMakeLists.txt for HelloWorld I want to simply do something like: > SET(requiredPackages MyLibA) > > My static library project "MyLibA" uses package "MyLibB" directly. In > the CMakeLists.txt for MyLibA I want to simply do something like: > SET(requiredPackages MyLibB) > > I want cmake to follow the package dependency chain so that my > HelloWorld executable project gets all the library file names and > include directories it needs to compile and link. If I change a file > in library B and rebuild my executable HelloWorld, I want it to detect > that it needs to rebuild package "MyLibB" and "MyLibA" and relink my > executable. > > I'd also like to handle different build types. If I build my project > in debug mode, i want it to use the debug versions of all the packages > it depends on (and not rebuild "release" versions that won't be used). > > Is cmake powerful enough to do this (and make it simple to use)? > > Does the "Mastering CMake" book explain how to do these basic sort of things? If I understand your questions, the answers are yes, and yes: CMake does everything you mention, and generally does it very well. The book is a good read, although this email list is a very helpful supplement. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] retraining Autoconf users on the command line
On 8/10/07, dave <[EMAIL PROTECTED]> wrote: > On Fri, Aug 10, 2007 at 04:11:38PM -0400, Brandon Van Every wrote: > > > > The biggest problems I've run into so far are all about translating > > nested IF(cond) logic. Especially since GMake can have "if" > > statements in makefile targets and CMake cannot. I've got solutions, > > but the problem begs for real parsing rather than regex hackery. > > > There is a super alternative to re matching in Phil Budne's Snobol4, which > just > happens to be available as open source at http://www.snobol4.org. It builds in > less than a minute on my 64-bit AMD 3500+ system running OpenBSD 4.1. > The program also is extremely portable - even runs on Windows with a little > help from cigwin or whatever it's called. CSnobol4 can be used as an > alternative > to sed and awk as well. Lotsa language tools out there really. Just a question of evaluating and choosing one. I'd look at Chicken Scheme first because it has pattern matching of some kind in it, and the regularized parentheses syntax is appropriate to parsing. It's a Scheme-to-C compiler so portability isn't a problem. I wrote the CMake build for it, so it'll run anywhere that CMake will. It has an active development community, so I'd be inclined to keep the momentum going with that. But I'm not married to Chicken Scheme for dealing with this problem if there's something way better out there. It just strikes me as a sensible place to begin. I spent 2 years jumping around between programming languages before I settled on Chicken Scheme, and I have nothing to show for that except broad exposure to a lot of languages. So I'm disinclined to go on any more hunting expeditions until I know I need to. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: POSIX regex support
On 8/10/07, Bill Hoffman <[EMAIL PROTECTED]> wrote: > Brandon Van Every wrote: > > > > I don't trust smileys, people may not notice them. The above was > > clearly a joke, except for the shooting part. > > > > Let me state the matter seriously. > > > > > Sure, it is a bad idea, and technically I agree with you. I would much > rather have seen the above paragraph But it's so... boring!! > without the, sick, depraved, and shooting part. > Lets try and keep > the discussion on the list technical in nature and avoid name calling. Fine, fine. OPTION(HUMORLESS "For those refusing to laugh" ON) Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Library dependency
I would like to use cmake to build a set of single target projects (each project generates either one library or one executable). I understand how to handle dependencies on external packages with the Find.cmake scripts, but I don't know how to deal with internal CMake built packages. There is some kind of magic with a Config.cmake that I don't understand. Here's a little high-level "use case" scenario to illustrate what I want to do: My executable project HelloWorld uses package "MyLibA" directly. In the CMakeLists.txt for HelloWorld I want to simply do something like: SET(requiredPackages MyLibA) My static library project "MyLibA" uses package "MyLibB" directly. In the CMakeLists.txt for MyLibA I want to simply do something like: SET(requiredPackages MyLibB) I want cmake to follow the package dependency chain so that my HelloWorld executable project gets all the library file names and include directories it needs to compile and link. If I change a file in library B and rebuild my executable HelloWorld, I want it to detect that it needs to rebuild package "MyLibB" and "MyLibA" and relink my executable. I'd also like to handle different build types. If I build my project in debug mode, i want it to use the debug versions of all the packages it depends on (and not rebuild "release" versions that won't be used). Is cmake powerful enough to do this (and make it simple to use)? Does the "Mastering CMake" book explain how to do these basic sort of things? Thanks for any help you can offer! -Kyle ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] making two targets with similar names
Juan Sanchez wrote:
> I am having the following issue. I want to create both a libFOO.a and a
> libFOO.so. Note that the libFOO.so is composed of more sources than the
> libFOO.a.
>
> I use OUTPUT_NAME in order so they have the same name. I can make the
> FOOSTATIC, libFOO.a, target, just fine. However, making the FOODYNAMIC,
> libFOO.so, target deletes libFOO.a, just before linking against it.
> This causes a build error.
>
> Is there anyway to prevent this from happening?
>
>
> ADD_LIBRARY (FOOSTATIC STATIC ${UDB_SRCS})
> ADD_LIBRARY (FOODYNAMIC SHARED ${PERL_SRCS})
I had the same problem but on a greater scale because I wanted all of
our libraries to be able to built either statically or dynamically and I
wanted it to be able to happen in the same build. The best solution I
came up with was to simply wrap every call to ADD_LIBRARY,
ADD_EXECUTABLE, and TARGET_LINK_LIBRARIES. Static targets get "-static"
appended to them and shared targets get "-shared" appended. Then I used
a "global" variable called LIB_TYPES to control whether I wanted static
and/or shared libraries built.
Probably overkill for your needs but here it is anyways...
#-
# MST_ADD_LIBRARY.
#-
#
# A wrapper for ADD_LIBRARY that gracefully handles creating static
# and shared library targets depending on the value of the list variable
# LIB_TYPES.
#
# If LIB_TYPES contains STATIC this function defines a static library
# target called ${library}-static
# If it contains SHARED ${library}-shared will be linked.
#
MACRO(MST_ADD_LIBRARY library)
FOREACH(type ${LIB_TYPES})
STRING(TOLOWER ${type} lc_type)
STRING(REGEX REPLACE "^sim" "" label ${library})
ADD_LIBRARY(${library}-${lc_type} ${type} ${ARGN})
SET_TARGET_PROPERTIES(${library}-${lc_type} PROPERTIES
PROJECT_LABEL ${label})
SET_TARGET_PROPERTIES(${library}-${lc_type} PROPERTIES
OUTPUT_NAME ${library})
SET_TARGET_PROPERTIES(${library}-${lc_type} PROPERTIES
CLEAN_DIRECT_OUTPUT 1)
ENDFOREACH()
ENDMACRO(MST_ADD_LIBRARY)
#-
# MST_ADD_EXECUTABLE.
#-
#
# A macro for creating one or two command line executable targets depending
# on the contents of the list variable BIN_TYPES.
#
# If BIN_TYPES contains STATIC, a static target is generated called
# ${mytarget}-static and the binary is built as ${mytarget}.
#
# If BIN_TYPES contains SHARED, a shared target is generated called
# ${mytarget}-shared and the binary is built as ${mytarget}.
#
# If BIN_TYPES contains both, the output name on the resulting targets is
# overriden to be ${mytarget}_static and ${mytarget}_shared resulting in:
#
# foo_static.exe
# foo_shared.exe
#
# This is meant to prevent overlap in the rare case when shared and static
# binaries are meant to be built concurrently. If the user doesn't like
this
# they can defined their own target names using ADD_EXECUTABLE.
#
MACRO(MST_ADD_EXECUTABLE mytarget)
FOREACH(type ${BIN_TYPES})
STRING(TOLOWER ${type} lc_type)
ADD_EXECUTABLE(${mytarget}-${lc_type} ${ARGN})
SET_TARGET_PROPERTIES(${mytarget}-${lc_type} PROPERTIES
OUTPUT_NAME ${mytarget})
SET_TARGET_PROPERTIES(${mytarget}-${lc_type} PROPERTIES
PROJECT_LABEL ${mytarget})
ENDFOREACH()
# This forces executable filename to be foo_static and foo_shared
# in the event the user wants both a static and shared target.
IF("${BIN_TYPES}" MATCHES "STATIC" AND "${BIN_TYPES}" MATCHES "SHARED")
SET_TARGET_PROPERTIES(${mytarget}-static PROPERTIES OUTPUT_NAME
${mytarget}_static)
SET_TARGET_PROPERTIES(${mytarget}-static PROPERTIES
PROJECT_LABEL ${mytarget}-static)
SET_TARGET_PROPERTIES(${mytarget}-shared PROPERTIES OUTPUT_NAME
${mytarget}_shared)
SET_TARGET_PROPERTIES(${mytarget}-shared PROPERTIES
PROJECT_LABEL ${mytarget}-shared)
ENDIF()
ENDMACRO(MST_ADD_EXECUTABLE)
#-
# MST_LINK_LIBRARY_AGAINST_EXTERNAL_LIBS.
#-
#
# A wrapper for TARGET_LINK_LIBRARIES that allows a static or shared library
# to be linked against a variety of external libraries.
#
# If LIB_TYPES contains STATIC this function will link the target
# ${library}-static against all subsequent arguments passed into the
function.
# If it contains SHARED ${library}-shared will be linked.
#
MACRO(MST_LINK_LIBRARY_AGAINST_EXTERNAL_LIBS library)
FOREACH(type ${LIB_TYPES})
STRING(TOLOWER ${type} lc_type)
TARGET_LINK_LIBRARIES(${library}-${lc_type} ${ARGN})
ENDFOREACH()
ENDMACRO(MST_LINK_LIBRARY_AGAINST_EXTERNAL_LIBS)
#---
Re: [CMake] Re: POSIX regex support
Brandon Van Every wrote: I don't trust smileys, people may not notice them. The above was clearly a joke, except for the shooting part. Let me state the matter seriously. Anyone who thinks that more control characters should be inserted into a regex stream, that has no wide based standard for why the control character is being so inserted, is making a very poor design decision. It is very difficult to keep the standard control characters straight as is, not to mention the CMake quirk of double \\ escapes due to argument processing. Please no more regex pain than everyone already has. I can just see the collective scream from all the regex gurus moving to CMake, when things that parsed fine in their old ways of doing things explode because now they have to deal with ~ as a special case. Sure, it is a bad idea, and technically I agree with you. I would much rather have seen the above paragraph without the, sick, depraved, and shooting part. Lets try and keep the discussion on the list technical in nature and avoid name calling. Thanks. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: POSIX regex support
On 8/10/07, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > On Friday 10 August 2007 15:55, Brandon Van Every wrote: > ... > > Totally horrible brain dead idea. If it weren't for your other > > suggestions, I'd say you should be shot. > ... > > You are a sick, depraved individual. > > Brandon, I think this went to far, maybe even if there would have been > smileys. > Please stay kind when replying to posts. I don't trust smileys, people may not notice them. The above was clearly a joke, except for the shooting part. Let me state the matter seriously. Anyone who thinks that more control characters should be inserted into a regex stream, that has no wide based standard for why the control character is being so inserted, is making a very poor design decision. It is very difficult to keep the standard control characters straight as is, not to mention the CMake quirk of double \\ escapes due to argument processing. Please no more regex pain than everyone already has. I can just see the collective scream from all the regex gurus moving to CMake, when things that parsed fine in their old ways of doing things explode because now they have to deal with ~ as a special case. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: POSIX regex support
On Friday 10 August 2007 15:55, Brandon Van Every wrote: ... > Totally horrible brain dead idea. If it weren't for your other > suggestions, I'd say you should be shot. ... > You are a sick, depraved individual. Brandon, I think this went to far, maybe even if there would have been smileys. Please stay kind when replying to posts. Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] retraining Autoconf users on the command line
On 8/10/07, dave <[EMAIL PROTECTED]> wrote: > > I understand your desire to be compensated for projects that have the > potential for being very large sinks of time and energy. I don't have > any real experience with gnu autotools. I have noticed that there are > *many* versions closely following each other in time. That suggests the > tools are evolving quickly and that makes them hard to track. That in turn > makes automated conversion tools fragile at best. We can certainly add snippets on how to do various Automake / Autoconf / GMake translations in the Tutorials section, in CMake script. This would give CMake translators a leg up on the learning curve. I'd want to see POSIX or PCRE regex in place before that though. It's pointless to teach everyone how to work around ^ and $ bugs with (\r?\n), or \\1 operators, or exclusions to get around the greedy matching. The biggest problems I've run into so far are all about translating nested IF(cond) logic. Especially since GMake can have "if" statements in makefile targets and CMake cannot. I've got solutions, but the problem begs for real parsing rather than regex hackery. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How do I disable -Wmost in XCode generation?
I appears that -Wmost is hard coded in the CFLAGS for XCode projects. Is there anyway to disable this without change the cmamke code and re-compiling it? Rick M ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: POSIX regex support
On 8/10/07, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote:
> Quoting Bill Hoffman <[EMAIL PROTECTED]>:
>
> > Pau Garcia i Quiles wrote:
> >>
> >> I took a quick look a few weeks ago and replacing the current regex
> >> library with PCRE seems "easy" (most of the work would be
> >> replacing the regexp's in current .cmake files with their POSIX
> >> equivalents). Is Kitware or anyone else already working on that?
> > Sounds like a backwards compatibility problem I am sure we would
> > break tons of projects if we changed the REGEX format in cmake.
> >
> >
> > -Bill
>
> That was my first thought, too, but we could keep backwards
> compatibility easily.
>
> It'd just be a matter of having something like:
> SET( REGULAR_EXPRESSIONS CMAKE_CLASSICAL)
> or
> SET( REGULAR_EXPRESSIONS POSIX)
Not the worst idea I've heard, but the scoping is definitely error prone.
> Even better, prepending an unusual-enough character we could have both
> regular expressions at once in the same project.
A questionable design goal, although perhaps justified for
intermediate migration purposes.
> Say we decide "~" is
> that character. If we write STRING( REGEX_MATCH "whatever" MYOUTVAR
> ${MYINPUTTEXT} ) CMake uses current regular expressions, if we write
> STRING( REGEX_MATCH "~whatever" MYOUTVAR ${MYINPUTTEXT} ) CMake uses
> POSIX regular epxressions. To match "~" we would use it escaped: "\~".
Totally horrible brain dead idea. If it weren't for your other
suggestions, I'd say you should be shot.
> Another option would be to have something like STRING(
> POSIX_REGEX_MATCH ...), etc
Yes please. No compatibility problems with that. Although I think
STRING(POSIX_REGEX MATCH ...)
STRING(POSIX_REGEX REPLACE ...)
is the way to go, rather than lumping everything into 1 keyword. Or
STRING(PCREGEX MATCH ...)
STRING(PCREGEX REPLACE ...)
since we're really talking "Perl Compatible Regular Expressions"
rather than POSIX, aren't we?
Make sure there's also a way to select non-greedy operators. This is
really important. I don't know how PCRE or POSIX does it.
> but I like the "~" better.
You are a sick, depraved individual.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: POSIX regex support
Pau Garcia i Quiles wrote: Another option would be to have something like STRING( POSIX_REGEX_MATCH ...), etc but I like the "~" better. I think this would be my choice... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: POSIX regex support
Quoting Bill Hoffman <[EMAIL PROTECTED]>:
Pau Garcia i Quiles wrote:
I took a quick look a few weeks ago and replacing the current regex
library with PCRE seems "easy" (most of the work would be
replacing the regexp's in current .cmake files with their POSIX
equivalents). Is Kitware or anyone else already working on that?
Sounds like a backwards compatibility problem I am sure we would
break tons of projects if we changed the REGEX format in cmake.
-Bill
That was my first thought, too, but we could keep backwards
compatibility easily.
It'd just be a matter of having something like:
SET( REGULAR_EXPRESSIONS CMAKE_CLASSICAL)
or
SET( REGULAR_EXPRESSIONS POSIX)
Even better, prepending an unusual-enough character we could have both
regular expressions at once in the same project. Say we decide "~" is
that character. If we write STRING( REGEX_MATCH "whatever" MYOUTVAR
${MYINPUTTEXT} ) CMake uses current regular expressions, if we write
STRING( REGEX_MATCH "~whatever" MYOUTVAR ${MYINPUTTEXT} ) CMake uses
POSIX regular epxressions. To match "~" we would use it escaped: "\~".
Another option would be to have something like STRING(
POSIX_REGEX_MATCH ...), etc but I like the "~" better.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] making two targets with similar names
Hi Bill,
Thanks, it works when I do this in SET_TARGET_PROPERTIES.
Juan
Juan Sanchez wrote:
> Hi Bill,
>
> What's the proper syntax? Setting the variable in CMakeLists.txt doesn't
> work. Neither does setting it in my initial Cache file (loaded with
> cmake -C).
>
> SET (CLEAN_DIRECT_OUTPUT 1 CACHE STRING "1")
>
> Thanks,
>
> Juan
>
> Bill Hoffman wrote:
>> Juan Sanchez wrote:
>>> I am having the following issue. I want to create both a libFOO.a and a
>>> libFOO.so. Note that the libFOO.so is composed of more sources than the
>>> libFOO.a.
>>>
>>> I use OUTPUT_NAME in order so they have the same name. I can make the
>>> FOOSTATIC, libFOO.a, target, just fine. However, making the FOODYNAMIC,
>>> libFOO.so, target deletes libFOO.a, just before linking against it.
>>> This causes a build error.
>>>
>>> Is there anyway to prevent this from happening?
>>>
>>>
>>> ADD_LIBRARY (FOOSTATIC STATIC ${UDB_SRCS})
>>> ADD_LIBRARY (FOODYNAMIC SHARED ${PERL_SRCS})
>>>
>>> target_link_libraries(FOODYNAMIC FOOSTATIC)
>>>
>>> SET_TARGET_PROPERTIES(FOODYNAMIC PROPERTIES
>>> LINK_FLAGS --whole-archive
>>> OUTPUT_NAME FOO
>>> )
>>>
>>> SET_TARGET_PROPERTIES(FOOSTATIC PROPERTIES
>>> OUTPUT_NAME FOO
>>> )
>>>
>> See the documentation for OUTPUT_NAME:
>>
>> When a library is built CMake by default generates code to remove any
>> existing library using all possible names. This is needed to support
>> libraries that switch between STATIC and SHARED by a user option.
>> However when using OUTPUT_NAME to build a static and shared library of
>> the same name using different logical target names the two targets will
>> remove each other's files. This can be prevented by setting the
>> CLEAN_DIRECT_OUTPUT property to 1.
>>
>>
>> -Bill
>>
>>
>>
>
>
--
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] making two targets with similar names
Hi Bill,
What's the proper syntax? Setting the variable in CMakeLists.txt doesn't
work. Neither does setting it in my initial Cache file (loaded with
cmake -C).
SET (CLEAN_DIRECT_OUTPUT 1 CACHE STRING "1")
Thanks,
Juan
Bill Hoffman wrote:
> Juan Sanchez wrote:
>> I am having the following issue. I want to create both a libFOO.a and a
>> libFOO.so. Note that the libFOO.so is composed of more sources than the
>> libFOO.a.
>>
>> I use OUTPUT_NAME in order so they have the same name. I can make the
>> FOOSTATIC, libFOO.a, target, just fine. However, making the FOODYNAMIC,
>> libFOO.so, target deletes libFOO.a, just before linking against it.
>> This causes a build error.
>>
>> Is there anyway to prevent this from happening?
>>
>>
>> ADD_LIBRARY (FOOSTATIC STATIC ${UDB_SRCS})
>> ADD_LIBRARY (FOODYNAMIC SHARED ${PERL_SRCS})
>>
>> target_link_libraries(FOODYNAMIC FOOSTATIC)
>>
>> SET_TARGET_PROPERTIES(FOODYNAMIC PROPERTIES
>> LINK_FLAGS --whole-archive
>> OUTPUT_NAME FOO
>> )
>>
>> SET_TARGET_PROPERTIES(FOOSTATIC PROPERTIES
>> OUTPUT_NAME FOO
>> )
>>
> See the documentation for OUTPUT_NAME:
>
> When a library is built CMake by default generates code to remove any
> existing library using all possible names. This is needed to support
> libraries that switch between STATIC and SHARED by a user option.
> However when using OUTPUT_NAME to build a static and shared library of
> the same name using different logical target names the two targets will
> remove each other's files. This can be prevented by setting the
> CLEAN_DIRECT_OUTPUT property to 1.
>
>
> -Bill
>
>
>
--
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: POSIX regex support
Pau Garcia i Quiles wrote: I took a quick look a few weeks ago and replacing the current regex library with PCRE seems "easy" (most of the work would be replacing the regexp's in current .cmake files with their POSIX equivalents). Is Kitware or anyone else already working on that? Sounds like a backwards compatibility problem I am sure we would break tons of projects if we changed the REGEX format in cmake. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] making two targets with similar names
Juan Sanchez wrote:
I am having the following issue. I want to create both a libFOO.a and a
libFOO.so. Note that the libFOO.so is composed of more sources than the
libFOO.a.
I use OUTPUT_NAME in order so they have the same name. I can make the
FOOSTATIC, libFOO.a, target, just fine. However, making the FOODYNAMIC,
libFOO.so, target deletes libFOO.a, just before linking against it.
This causes a build error.
Is there anyway to prevent this from happening?
ADD_LIBRARY (FOOSTATIC STATIC ${UDB_SRCS})
ADD_LIBRARY (FOODYNAMIC SHARED ${PERL_SRCS})
target_link_libraries(FOODYNAMIC FOOSTATIC)
SET_TARGET_PROPERTIES(FOODYNAMIC PROPERTIES
LINK_FLAGS --whole-archive
OUTPUT_NAME FOO
)
SET_TARGET_PROPERTIES(FOOSTATIC PROPERTIES
OUTPUT_NAME FOO
)
See the documentation for OUTPUT_NAME:
When a library is built CMake by default generates code to remove any
existing library using all possible names. This is needed to support
libraries that switch between STATIC and SHARED by a user option.
However when using OUTPUT_NAME to build a static and shared library of
the same name using different logical target names the two targets will
remove each other's files. This can be prevented by setting the
CLEAN_DIRECT_OUTPUT property to 1.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CONFIGURE_FILE won't overwrite existing file?
Christian Convey schrieb: It looks to me like CONFIGURE_FILE is a no-op when the target file already exists *and* has the exact same content that it would have if CONFIGURE_FILE ran. I'm basing me belief by looking running some experiments and looking at timestamps. But this isn't mentioned in the online docs for CONFIGURE_FILE. Does anyone know if it works the way I describe? That's correct - otherwise all your sources (which includes the config file) would get recompiled after each cmake run. Christian signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CONFIGURE_FILE won't overwrite existing file?
Yes it does... It's a "copy if different" operation. On 8/10/07, Christian Convey <[EMAIL PROTECTED]> wrote: > It looks to me like CONFIGURE_FILE is a no-op when the target file > already exists *and* has the exact same content that it would have if > CONFIGURE_FILE ran. > > I'm basing me belief by looking running some experiments and looking > at timestamps. > > But this isn't mentioned in the online docs for CONFIGURE_FILE. > > Does anyone know if it works the way I describe? > > - Chrsitian > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
POSIX regex support (was: Re: [CMake] Any suggestions for packaging a bizillion subprojects?)
Quoting Brandon Van Every <[EMAIL PROTECTED]>: On 8/10/07, Christian Convey <[EMAIL PROTECTED]> wrote: What I'm trying to avoid is having to go into all 70 of those subdirectories and modifying each of those 70 CMakeLists.txt files, adding an INSTALL command to each file. Why avoid that? You could just write some regex replaces in CMake script and make a fairly trivial job out of it. Or use some other language you know with regex support, like Ruby. But for some reason I think it's cool to use CMake script to modify CMake stuff. CMake's regex had some bugs and limitations. ^ and $ are broken with respect to multi-line input, see bug #5380. So you end up doing a lot of \n and (\r?\n) stuff. Matches are greedy, there's no non-greedy matching available, which makes some problems difficult. I've got code to work around that if you're interested though. If I already knew Ruby I would have used that, but I didn't. Ruby looks like it's got the best regex support, in languages more modern than Perl. Python implements regexes externally, not as convenient. I took a quick look a few weeks ago and replacing the current regex library with PCRE seems "easy" (most of the work would be replacing the regexp's in current .cmake files with their POSIX equivalents). Is Kitware or anyone else already working on that? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CONFIGURE_FILE won't overwrite existing file?
It looks to me like CONFIGURE_FILE is a no-op when the target file already exists *and* has the exact same content that it would have if CONFIGURE_FILE ran. I'm basing me belief by looking running some experiments and looking at timestamps. But this isn't mentioned in the online docs for CONFIGURE_FILE. Does anyone know if it works the way I describe? - Chrsitian ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] making two targets with similar names
I am having the following issue. I want to create both a libFOO.a and a
libFOO.so. Note that the libFOO.so is composed of more sources than the
libFOO.a.
I use OUTPUT_NAME in order so they have the same name. I can make the
FOOSTATIC, libFOO.a, target, just fine. However, making the FOODYNAMIC,
libFOO.so, target deletes libFOO.a, just before linking against it.
This causes a build error.
Is there anyway to prevent this from happening?
ADD_LIBRARY (FOOSTATIC STATIC ${UDB_SRCS})
ADD_LIBRARY (FOODYNAMIC SHARED ${PERL_SRCS})
target_link_libraries(FOODYNAMIC FOOSTATIC)
SET_TARGET_PROPERTIES(FOODYNAMIC PROPERTIES
LINK_FLAGS --whole-archive
OUTPUT_NAME FOO
)
SET_TARGET_PROPERTIES(FOOSTATIC PROPERTIES
OUTPUT_NAME FOO
)
Thanks,
Juan
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Any suggestions for packaging a bizillion subprojects?
On 8/10/07, Christian Convey <[EMAIL PROTECTED]> wrote: > > What I'm trying to avoid is having to go into all 70 of those > subdirectories and modifying each of those 70 CMakeLists.txt files, > adding an INSTALL command to each file. Why avoid that? You could just write some regex replaces in CMake script and make a fairly trivial job out of it. Or use some other language you know with regex support, like Ruby. But for some reason I think it's cool to use CMake script to modify CMake stuff. CMake's regex had some bugs and limitations. ^ and $ are broken with respect to multi-line input, see bug #5380. So you end up doing a lot of \n and (\r?\n) stuff. Matches are greedy, there's no non-greedy matching available, which makes some problems difficult. I've got code to work around that if you're interested though. If I already knew Ruby I would have used that, but I didn't. Ruby looks like it's got the best regex support, in languages more modern than Perl. Python implements regexes externally, not as convenient. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: deprecated static libraries on Mac
On 8/10/07 1:16 PM, Bill Hoffman said: both supported, I build both. On the Mac, where static libraries are officially depreciated, I don't. There's an OPTION to build them if you really really want to scrounge around with that. And if you want >>> I haven't heard this, albeit I don't do much Mac development. Do you >have any >>> references on this. A project I'm working on wants to build static >libraries to >>> help in the distribution: "Here's your binary, now RUN!". >>> >> >> http://developer.apple.com/qa/qa2001/qa1118.html >> >I am not sure this means static libraries are deprecated. It just >means that completely static >executables are not recommended. They want you to use the dynamic run >time libraries. >This is very similar to the MS compiler. However, your application can >use lots of static >libraries that contain your code. Precisely. Just look in /usr/lib/, Mac OS X ships with all kinds of .a (ie static) libraries. -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] retraining Autoconf users on the command line
On 8/10/07, dave <[EMAIL PROTECTED]> wrote: > On Fri, Aug 10, 2007 at 12:38:08PM -0400, Brandon Van Every wrote: > > > > The command line is the retraining tool. > > How about a CMake utility that accepts autotools files as input > and creates CMake output files for all the autotools features which > can be translated directly and then flagging with comments the features > in the input tools which need to (for whatever reason) be converted by > hand? Sure. You wanna pay me by the hour to write it? I'm doing a quick 'n' dirty translation of GMake to CMake right now for a client, using CMake script. It's feasible in a reasonable timeframe because I don't have to deal with arbitrary inputs, I only have to deal with actual coding styles present in their (rather large) source tree. Then I can throw the translation script away. Or they could bang on it more, or pay me to bang on it more, extending its life. Trying to do this for arbitrary inputs, and making it robust, looks like a big job. You seen all the crap that GMake has in it? Nevermind that Automake is not Autoconf is not GMake. There are some Automake parsers from the KDE project, but the only GMake parser I found was http://search.cpan.org/~agent/Makefile-Parser-0.17/lib/Makefile/Parser.pm The risk of bothering to understand it didn't look good, so I blew it off. At present I'm simply doing "have regex, will translate." If I had time, budget, and mandate, I'd probably do it in a language more suited to parsing, such as Chicken Scheme. Or maybe go back to OCaml. But the truth is, I'm currently a way better CMake buildmaster than a Scheme programmer, so I went with what I know best, which is CMake script. I think open source translation tools will exist and become more robust eventually, but meanwhile, they're very time consuming to write and people have gotta get paid to deal with stuff. I mean, has Kitware up and written one? No, so clearly they have other priorities about where to put the heavy labor. I feel similarly in the absence of money. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: deprecated static libraries on Mac
Brandon Van Every wrote: On 8/10/07, Bill Hoffman <[EMAIL PROTECTED]> wrote: Brandon Van Every wrote: http://developer.apple.com/qa/qa2001/qa1118.html I am not sure this means static libraries are deprecated. It just means that completely static executables are not recommended. They want you to use the dynamic run time libraries. This is very similar to the MS compiler. However, your application can use lots of static libraries that contain your code. The OS X linker will go out of its way to sabotage your code. If you have a static and a dynamic library of the same rootname in your path, it will always prefer the dynamic library, no matter what flags you specify. libtool does some kind of dance to get around this; CMake does not. If Apple is going to be that heavy handed with their linker, then as far as I'm concerned, they're aggressively anti-static and you're opening up cans 'o' worms going against them. I suppose static libs under my own control that link against dynamic runtimes are possible, but I'm not a Mac guy and do not deeply care about the issue. I adopted the expedient of suppressing static anything in Chicken's Mac build. You can use this flag for ld if you want to change that: -search_paths_first By default when the -dynamic flag is in effect, the -lx and -weak-lx options first search for a file of the form `libx.dylib' in each directory in the library search path, then a file of the form `libx.a' is searched for in the library search paths. This option changes it so that in each path `libx.dylib' is searched for then `libx.a' before the next path in the library search path is searched. At one, point I considered making this the default in CMake If you are building the libraries and there are only static ones, it will use them. So, to say they are deprecating static libraries is a bit of an over statement. They want you to use shared libraries, yes, but they are not getting rid of static ones. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: deprecated static libraries on Mac
On 8/10/07, Bill Hoffman <[EMAIL PROTECTED]> wrote: > Brandon Van Every wrote: > > > > http://developer.apple.com/qa/qa2001/qa1118.html > > > I am not sure this means static libraries are deprecated. It just > means that completely static > executables are not recommended. They want you to use the dynamic run > time libraries. > This is very similar to the MS compiler. However, your application can > use lots of static > libraries that contain your code. The OS X linker will go out of its way to sabotage your code. If you have a static and a dynamic library of the same rootname in your path, it will always prefer the dynamic library, no matter what flags you specify. libtool does some kind of dance to get around this; CMake does not. If Apple is going to be that heavy handed with their linker, then as far as I'm concerned, they're aggressively anti-static and you're opening up cans 'o' worms going against them. I suppose static libs under my own control that link against dynamic runtimes are possible, but I'm not a Mac guy and do not deeply care about the issue. I adopted the expedient of suppressing static anything in Chicken's Mac build. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
On 8/10/07, Bill Hoffman <[EMAIL PROTECTED]> wrote: > Brandon Van Every wrote: > > > > > > It might be reasonable, however, to show OPTIONS resolved at the > > current scope. And to note whether conditional options exist, i.e. > > "Warning: conditional options detected. You are advised to run > > (CMakeSetup|CCMake) and resolve them iteravely." Or the opposite: > > "All options have been resolved." > > > There is no way to do this, because the code inside an if(FALSE) is > never run, so there > would be no way to know if an option command was being skipped. Well, it's not strictly necessary to do the detection. There could be static Caveat Emptor text saying, "Warning, additional options may be available, you are advised to run CMake iteravely" or whatever the proper wordsmithing would be. You could take a count of the number of OPTION commands you've actually run, and compare that to the number of OPTION commands in all included files. If an OPTION is inside a loop or macro, you could automatically issue the warning that there *may* be more options available. I think realistically, a lot of CMakeScript.txt will have "flat" OPTION specifications and a counting compare will work. Proving that all options at this scope have been resolved may be more difficult, or non-doable in some cases. But in some cases it is doable. >From the Autoconf retraining standpoint, "Some OPTIONs detected in loops, you'll need to evaluate iteravely" is good geekery. It teaches the Autoconf user that OPTIONs are not static. On the other hand, static text saying "there may be conditional OPTIONs, there may be dynamic OPTIONs" accomplishes the training objective with no real work. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: deprecated static libraries on Mac
Brandon Van Every wrote: On 8/10/07, James Bigler <[EMAIL PROTECTED]> wrote: both supported, I build both. On the Mac, where static libraries are officially depreciated, I don't. There's an OPTION to build them if you really really want to scrounge around with that. And if you want I haven't heard this, albeit I don't do much Mac development. Do you have any references on this. A project I'm working on wants to build static libraries to help in the distribution: "Here's your binary, now RUN!". http://developer.apple.com/qa/qa2001/qa1118.html I am not sure this means static libraries are deprecated. It just means that completely static executables are not recommended. They want you to use the dynamic run time libraries. This is very similar to the MS compiler. However, your application can use lots of static libraries that contain your code. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
Brandon Van Every wrote: It might be reasonable, however, to show OPTIONS resolved at the current scope. And to note whether conditional options exist, i.e. "Warning: conditional options detected. You are advised to run (CMakeSetup|CCMake) and resolve them iteravely." Or the opposite: "All options have been resolved." There is no way to do this, because the code inside an if(FALSE) is never run, so there would be no way to know if an option command was being skipped. Is it possible to resolve them iteravely from the command line? I've had no reason to try that, but in principle, could you hammer the cache over and over again until it worked? You'd need feedback to know what the conditional options are. Is there any mechanism to do that at present, or do we need the OPTIONS readout as suggested above? cmake -i will do that. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: deprecated static libraries on Mac
On 8/10/07, James Bigler <[EMAIL PROTECTED]> wrote: > > both supported, I build both. On the Mac, where static libraries are > > officially depreciated, I don't. There's an OPTION to build them if > > you really really want to scrounge around with that. And if you want > > I haven't heard this, albeit I don't do much Mac development. Do you have any > references on this. A project I'm working on wants to build static libraries > to > help in the distribution: "Here's your binary, now RUN!". http://developer.apple.com/qa/qa2001/qa1118.html Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] retraining Autoconf users on the command line
On 8/10/07, Bill Hoffman <[EMAIL PROTECTED]> wrote: > Basically this requires a paradigm shift for autotools users. This discussion makes me think we need to see the fundamental problem differently. These are not "CMake is ugly, CMake lacks something" problems. Rather, CMake has a lot of things that a new user, coming from an Autoconf background, simply doesn't know about. We should be working on how to retrain Autoconf users, not looking at how to give them every capability that superficially, looks like what they want and are used to. I don't think it's reasonable to expect Autoconf users to read docs, whitepapers, wikis, or mailing lists to get their retraining. Autoconf users are, frankly, a lazy crowd. Their honed instinct is to go straight to the command line, and type "./configure; make; make install". They've done this thousands of times; it's not just second nature, it's a right! If it doesn't work, they howl. If they have to install or deploy something, if it isn't implemented in Bourne shell script, they howl. So I think we need to see the command line as the place where we have an opportunity - indeed, an obligation - to retrain the Autoconf users. We should assume that if a user is mucking around on the command line with CMake, they're an Autoconf user. When such a user types various commands, whether "./cmake" or "cmake -p" or "cmake -v" or whatever, part of the output should be text that briefly makes 2 important points: 1) that we've anticipated their design concern, but CMake does it differently for good reasons. For instance, "CMake uses iterative resolution of OPTIONS, you'll need to..." 2) that they really should be doing it the CMake way. "Use CMakeSetup|CCMake to configure..." The command line is the retraining tool. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
On 8/10/07, Eric Noulard <[EMAIL PROTECTED]> wrote: > > I think I perfectly understand your point but I would > say that adding "pre-parsing" phase where > The main CMakeLists.txt "pre-parsed" in order to list > the OPTION and their desc statement would indeed be feasible > > cmake -p would show INCONDITIONAL OPTION > cmake -p -v may show ALL OPTION flagging those which > may not be "resolved" without running CMake. We're getting into the realm of philosophy here. Do we want to condition the user to have an incessant need to know all the options available, whether or not they are appropriate or will help him? Or do we want to condition him to accept the information hiding mechanisms that CMake employs? I think the latter. It might be reasonable, however, to show OPTIONS resolved at the current scope. And to note whether conditional options exist, i.e. "Warning: conditional options detected. You are advised to run (CMakeSetup|CCMake) and resolve them iteravely." Or the opposite: "All options have been resolved." Is it possible to resolve them iteravely from the command line? I've had no reason to try that, but in principle, could you hammer the cache over and over again until it worked? You'd need feedback to know what the conditional options are. Is there any mechanism to do that at present, or do we need the OPTIONS readout as suggested above? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
On 8/10/07, Eric Noulard <[EMAIL PROTECTED]> wrote: > > I think there is a confusion here. >./configure does not give you "full help" unless the writer >of the configure scripts did it using --enable-xx or --with-xxx. >I may well write ugly configure.ac (in fact I did it in the past) >which won't help you AT ALL, even if the script will do its jobs >perfectly. Seconded. The vast majority of --enable-with-xxx options I've seen are thoroughly tweaky and obfuscated, like why the heck would I bother figuring out all of that? I just want to set the basics that are common to all builds (like debug vs. optimize) and have everything work with the push of 1 button. Perhaps a power user wants and even needs all those compilation options, but mostly it's just bad build design to be presenting the masses with legions of options. Mostly your build should just produce whatever people are actually likely to need in the real world, this should be the default. For instance, I don't ask whether the user wants to build shared or static libraries, it's a dumb question. On platforms where they're both supported, I build both. On the Mac, where static libraries are officially depreciated, I don't. There's an OPTION to build them if you really really want to scrounge around with that. And if you want to scrounge around, I figure you'd better know what you're doing and I don't mind if you have to comb through CMakeLists.txt to verify what you're doing. > >May be CMake user should be taught to use more OPTION >in order to give more informations (using OPTION description) >to the user. I think the Help button in CMakeSetup does tell the user what they need to do. Is that text not clear enough? Now, maybe the user won't hit the Help button? Mousing over the cache entries does produce info in the status bar. Right-clicking gives appropriate choices, including help. The only training improvement I can see here is maybe including balloon help. Maybe flashing the status bar so it's more noticeable would have the same effect. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Any suggestions for packaging a bizillion subprojects?
I've got a top-level directory with *70* subdirectories. Each subdirectory defines a sub-PROJECT (I'm not sure this was necessary), and typically one build target (either a library or program). I want to define two INSTALL components, which collectively will install all 70 targets. At my top-level source directory, I've already defined two CMake variables, each of which lists the subdirectories whose targets belong in the two different INSTALL components. Is there some kind of CMake code I can write, at the top-level CMakeLists.txt file, that will add each of the 70 subdirectories' build targets to the appropriate INSTALL component? What I'm trying to avoid is having to go into all 70 of those subdirectories and modifying each of those 70 CMakeLists.txt files, adding an INSTALL command to each file. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
Eric Noulard wrote: 2007/8/10, Bill Hoffman <[EMAIL PROTECTED]>: The process for configuring a cmake project has to be iterative because options can be nested inside if statements. ccmake, cmake -i and CMakeSetup all do the following: 1. Configure 2. Write CMakeCache.txt 3. Did the CMakeCache.txt change ? Yes-> Go back to 1 4. Allow the user to generate the project files. Given this, it will be impossible for a cmake project to ever automatically have cmake --help. I think I perfectly understand your point but I would say that adding "pre-parsing" phase where The main CMakeLists.txt "pre-parsed" in order to list the OPTION and their desc statement would indeed be feasible cmake -p would show INCONDITIONAL OPTION cmake -p -v may show ALL OPTION flagging those which may not be "resolved" without running CMake. I don't ask you (or Kitware) to do it since I personally don't NEED the feature. However, I wanted to note that it seems "possible". This may be an unwanted feature though if we wants CMake users to be fully "aware" of the CMake way of run you've described. I still don't think it is possible. What about multi-projects. For example, in ParaView, it includes a complete copy of VTK. Both projects have options, and all the options are not in the top level CMakelists.txt file for the project. VTK also includes tiff, jpeg, and several other small projects. CMake makes it very easy to combine projects. So, this feature of parsing the top level CMakeLists.txt would only work for very small "toy" projects, and fail on larger more complicated projects. I suppose you could add a file at the top of a project that was something like cmakeUserOptions.cmake, and the developer would be responsible for making sure it was up-to-date with the rest of the project. But, I see no reliable way to automatically figure out the list of options for a project until you run the code. Basically this requires a paradigm shift for autotools users. IMO, the CMake model is much more powerful as it scales to very large code bases, and allows for easy additions of optional features for a build. However, the price you pay is that you can not tell what the options are until you run and interact with the project. Basically, I and other CMake developers have given this a great deal of thought in the past, and there really does not appear to be a good way to do this... But if anyone can come up with a patch that is reasonable and works on more than toy projects, I am willing to take a look... :-) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
2007/8/10, Bill Hoffman <[EMAIL PROTECTED]>: > > The process for configuring a cmake project has to be iterative because > options can > be nested inside if statements. ccmake, cmake -i and CMakeSetup all do > the following: > > 1. Configure > 2. Write CMakeCache.txt > 3. Did the CMakeCache.txt change ? Yes-> Go back to 1 > 4. Allow the user to generate the project files. > > Given this, it will be impossible for a cmake project to ever automatically > have > cmake --help. I think I perfectly understand your point but I would say that adding "pre-parsing" phase where The main CMakeLists.txt "pre-parsed" in order to list the OPTION and their desc statement would indeed be feasible cmake -p would show INCONDITIONAL OPTION cmake -p -v may show ALL OPTION flagging those which may not be "resolved" without running CMake. I don't ask you (or Kitware) to do it since I personally don't NEED the feature. However, I wanted to note that it seems "possible". This may be an unwanted feature though if we wants CMake users to be fully "aware" of the CMake way of run you've described. -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
. (lots of stuff). Since CMake is a language that is parsed when cmake is run, there is no way to present the user with all possible options until you run cmake. Options can be included inside an if statement. This is actually a good thing. For example, if the user enables VTK_PARALLEL, then and only then are they presented with the options for finding MPI. This avoids presenting all options as a configure --help might do. Even if those options depend on each other. There are two levels of options advanced and non-advanced. It is best to only have a few options as non-advanced. Used correctly, this can avoid giving a user too many options up front. The process for configuring a cmake project has to be iterative because options can be nested inside if statements. ccmake, cmake -i and CMakeSetup all do the following: 1. Configure 2. Write CMakeCache.txt 3. Did the CMakeCache.txt change ? Yes-> Go back to 1 4. Allow the user to generate the project files. Given this, it will be impossible for a cmake project to ever automatically have cmake --help. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Error when run bootstrap on MinGW
Hello! I have try to build CMake for Win23/MinGW When I run the bootstrap i get an Error! --- C:\svn_tools\branches\bin\win32\mingw-3.4.5\bin\make: *** No rule to make target `/c/temp/cmake-2.4.7/cmake-2.4.7/Source/cmake.cxx', needed by `cmake.o'. Stop. --- ?? Have try different parameters but same Error When I running bootstrap on a Linux host (with the cmake for Linux) all is OK What can be wrong? Best Regards CNW Tew __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to query Build Type from Visual Studio IDE using CMake?
Hello, I want to read the current state (build type debug/release) out of Visual Studio 2005 using CMake. I tried a lot of things. Please can anyone help me? Thanks, Markus ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Build Type Visual Studio IDE
Hello, I want to read the current state (build type debug/release) out of Visual Studio 2005 using CMake. I tried a lot of things. Please can anyone help me? Thanks, Markus ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] --enable-* with cmake
2007/8/10, gga <[EMAIL PROTECTED]>: > Brandon Van Every wrote: > > On 8/8/07, gga <[EMAIL PROTECTED]> wrote: > >> I know I can pass -D symbols to cmake to modify its behavior and that > >> windows also has its ugly CmakeSetup gui. > > > > "Ugly?" Geez, what are you, a candidate for Windows Aero or something? > > > > No, I am a candidate for something that works and ccmake/cmakesetup does > not work well. Don't confuse eye candy with functionality. When I mean > ugly, I mean there's basic functionality missing from ccmake/cmakesetup. I think this is clearer :)) And the list you gave afterwards is interesting, I'll give my point of view on each item below. > This, unfortunately, clearly rules cmake from being a good candidate to > replace autotools, even if its core is much better. > > The problems with the current approach are: > - Variables for configuration are unknown to the user unless he > digs into all of the cmake modules used. > Compare this to running any autotools project: >./configure > (you get full help for all the libs and options you can use). I think there is a confusion here. ./configure does not give you "full help" unless the writer of the configure scripts did it using --enable-xx or --with-xxx. I may well write ugly configure.ac (in fact I did it in the past) which won't help you AT ALL, even if the script will do its jobs perfectly. May be CMake user should be taught to use more OPTION in order to give more informations (using OPTION description) to the user. > >./cmake >(I get cmake's documentation, nothing about my project) > ../ccmake (on a clean project) >(Nothing) You are right this is annoying, I would very much like cmake / ccmake tell me something about my project if called in a build tree or a pristine source tree. They may list the project name and possibly the list of available OPTION with desc line. Something that mimics the behavior of ant -p (with the added verbose mode ant -v -p, which gives you even more informations) for compatibility reason I would avoid doing this when cmake is invoked without option but telling the user that a cmake -p will do the job. > > - ccmake/cmakesetup list variables in the cache only. > If you are building out of source (as I do), the > CMakeCache.txt and the CMakeLists.txt are in > different directories, which again can be confusing to a user. I think a CMake user must be taught to understand out-of-source build there nothing CMake can (implicitly) do about this. However CMake supports in-source build too, such that "young" CMake user may continue to do in-source build. As a side note autotools does support out-of-source build but how many "occasional" ./configure user out there do use out of source build with autotools? Moreover I was pretty disappointed to discover that autoconf+automake do generates "some" files in my source tree even if I do out of source build (missing, install-sh etc...) This is a real annoyance because when you use the same source tree to build on different hosts using different version set of autoconf/automake sometimes you get message like this: == make distclean cd ../CERTI && /bin/sh /udd/deri/enoulard/workspace/CERTI/missing --run automake-1.8 --gnu /udd/deri/enoulard/workspace/CERTI/missing: line 52: automake-1.8: command not found WARNING: `automake-1.8' is missing on your system. You should only need it if you modified `Makefile.am', `acinclude.m4' or `configure.in'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. cd . && /bin/sh ./config.status Makefile === even if the current machine a a perfectly running automake-1.10 !! > - As ccmake/cmakesetup rely on cached variables, a user running > the project for the first time will not get ANY variables > when he runs ccmake. He HAS to run cmake first. I agree this is really puzzling, thoses tools should "at least" show you OPTION with associated desc lines. However this is not as easy as it seems because you may well have "optional" OPTION, i.e. which are OPTION defined if some other things discovered at CMake run time may enable/disable. In fact the only mean to know what option are available is to run CMake once... > - ccmake/cmakesetup lists pretty much ALL variables. > Scary as he
RE: [CMake] Visual Studio solutions
I wrote: > when I use the "Visual Studio 7 .NET 2003" generator, CMake generates > one .vcproj file for each library/application, > and one .sln file that contains all the .vcproj files, with > appropriate dependencies. So far so good. > > What I would like in addition is a .sln file for each application, so > that a developer working on that application > does not have to load the full solution file. Is this possible? Well, it turned out that the reason was simply that I did not have a "PROJECT" statement in each application's CMakeLists.txt (as Brandon pointed out). With the PROJECT statement, the desired number of .sln files is generated - however, the generated dependencies are not correct. Manuel Klimek let me know that he had implemented a patch to fix this (http://www.cmake.org/Bug/view.php?id=3218). I have updated the patch for 2.4.7, and I am now deploying the patched version to my group. I hope this patch will be included in the next version. -Torsten This e-mail and any files sent with it contain information that may be privileged or confidential and is the property of the GateHouse Group. This information is intended solely for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use the message or any part thereof. If you have received this e-mail in error, please notify the sender immediately, and delete all copies of this message. In accordance with GateHouse Security Policy, e-mails sent or received may be monitored. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] ifort and the visual studio generator
This is the second try, since gmane seems to swallowed the first one... Hello, I have trouble when trying to run the "Visual Studio 7" generator on a Fortran project, while "NMake Makefiles" works fine. The installed fortran compiler is intels ifort. A minimal test case: project(foo Fortran) add_executable(main main.f) c This is the code snippet which is used by the TRY_COMPILE c in CMakeTestFortranCompiler.cmake PROGRAM TESTFortran PRINT *, 'Hello' END CMake fails with: ... Building Fortran object testFortranCompiler.obj Linking Fortran target cmTryCompileExec.exe Fatal error cannot open "ifconsol" ... where ifconsol refers to libifconsol.lib which in my case in c:\Compiler\Intel\Compiler\Fortran\9.0\IA32\Lib\ The next thought is LIB isn't set proper, but 1. C:\Compiler\Intel\Compiler\Fortran\9.0\IA32\Lib;c:\Programme\Microsoft Visual Studio .NET\Vc7\PlatformSDK\lib\;c:\Programme\Microsoft Visual Studio .NET\Vc7\lib\;d:\users\gck_mb\Qt\4.2.2\lib; 2. > $ifort main.f works perfect 3. > cmake -G"NMake Makefiles" ../ > nmake works perfect too Thanks in advance, Maik Beckmann ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
