Re: [CMake] VS makefiles
On Jan 23, 2008 4:58 PM, Steven Van Ingelgem <[EMAIL PROTECTED]> wrote: > Hi, > > > I was wondering why there are no VS makefiles? (run like nmake -f > project.mak). If you're looking for nmake support, that is there. If you're looking for VS support of Makefiles, VS 6.0 was the last version to support them. Since none of the more recent VS versions understand Makefiles, it makes sense that the capability is not supported for the rather old VS 6.0 generator. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why SET() not support regular expression ?
On Jan 23, 2008 3:51 PM, pepone. onrez <[EMAIL PROTECTED]> wrote: > > Maybe a macro can call cmake for only this part that need to be regenerated, > in this way if the macro detects thats a glob has changed it can recreate > rules that´s depends upon this GLOB, Only and idea what you think about > this? file(GLOB var pattern) simply outputs a variable "var". So you are talking about determining arbitrary program execution based on the value of the var. In practice I don't see how you'd cleanly separate that. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: [Plug] Perspective
On Jan 22, 2008 12:46 PM, Alvah Whealton <[EMAIL PROTECTED]> wrote: > On Jan 21, 2008 6:06 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > > With this kind of programming background, I don't see what the big > > deal about a text editor is. > > I was not at all gifted technically. I have learning disabilities > and always struggled for everything I got. But if one considers the > ability to appreciate the significance of things and to experience a > sense of wonder in things we encounter, I was perhaps blessed in that. Ah, ok. I'm pretty impatient, I often let myself be bored by things too easily. > text > processing in conjunction with email enabled me to escape isolation, > and enabled me to make a number of significant and lasting friendships > throughout the world. The internet is cool! It's usually what I turn to when I'm bored. Half the time it's people that rejuvenate me. The other half of the time, information. Really it's quite a remarkable step in human evolution, to have so much access. >It is easy to lose sight of how many people are still marginalized > with respect to computers. The greater Linux community has the best > chance of guiding a lot of elderly people, disabled people, and poor > people to low cost computers, free software and a mentoring process > which reflects genuine community values. And I have to believe, from > my own experience, that what they stand to gain is not just a hobby > but something which offers a means of enhancing their lives. And so > much of it is built on text processing. Interesting proposition. I agree about the community values, and it seems people around here are willing to do the training. I see problems regarding documentation and ease of use. These are problems not just with Linux, but with Open Source generally. I see emacs and vi as instances of that problem. Scite is better but I wouldn't recommend it to a non-technical person. It's still a technical text editor, with most of the bells and whistles of emacs and vi. It's just a lot leaner and meaner. Word processing is an easier problem as it tends to connote WYSIWYG sensibilities anyway. Lately I'm using AbiWord. http://www.abisource.com/ It almost does what Word 2000 does, but currently it requires outlines for table boxes, it can't just render the contents of the boxes without an outline. The latter is how my resume is formatted, so I'm not free of Word 2000 yet. I think there are some forces in the Linux universe, such as Ubuntu and KDE, that are headed in the right direction regarding ease of use. They're just not quite there yet. Ubuntu and KDE cultures are rather different from emacs and vi cultures. > > Now, thanks to the internet, any kid with technical ability has access > > to HUGE resources. Techies are incredibly empowered, and the > > limitations are more systemic and cultural than technical. Text > > editing is now old hat. Lots of conventions exist for GUIs that have > > been pioneered by Apple and popularized by Microsoft. Lots of > > standard libraries to manipulate fonts are available. From this > > perspective, vi is a dinosaur that survives only because text shells > > are still used. > > I certainly don't mean this to be offensive, but I think that > perspective is a bit narrow. It allows for your creative needs, but it > does not necessarily address the creativity of others. I'd like to see the creativity of the vim community applied towards easier to use software. There's a lot of stuff out there that may be personally creative and empowering, but is technically repetitive. Some people are extreme in this regard. For instance, I have a friend who's autistic and rather gifted as far as his ability to sling raw code. But he's forever reinventing the wheel from scratch. He has seemingly no capacity to work with other people, build on what has come before him, or contribute new value to techiedom. He could contribute *in theory* but he never sticks with his self-invented works long enough to make them usable to anyone else. He never deals with problems according to what's easy for other people to use, only what works for him. So although I recognize his programming process is very useful to him personally - it's his psychological maintenance tool - sometimes I just want to pull my hair out about how generally useless it is to others. My autistic friend is an extreme instance of this. I see vim as a much lesser instance. People use vim, no doubt about that. But it is a limited audience. I think vi's popularity is driven mostly by the installed base, not technical merit. It takes a long time to retire a tool when it's got a huge critical mass behind it. For Integra
Re: [CMake] Re: Custom build step
On Jan 21, 2008 8:39 AM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > then ADD_DEPENDENCIES(mylib DEPENDS blah). Er, add_dependencies(mylib blah). Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Custom build step
On Jan 21, 2008 7:40 AM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> On Jan 21, 2008 6:16 AM, pepone. onrez <[EMAIL PROTECTED]> wrote:
> >
> > SET ( COPY_FILE cp -v )
>
> Better: ${CMAKE_COMMAND} -E copy
> Type cmake -E for details of OS portable commands.
>
> Your example build fails on Cygwin with the same problem.
Ok, here's the essence of what your code does. In the future when
providing a "trivial reproducer" for a problem, it would be best to
strip it down to this level. One very simple CMakeLists.txt, no
subdirectories, no long variable names, no extraneous stuff. To the
degree that you can, of course.
project(copygen)
SET(f0 sample.g)
STRING( REGEX REPLACE "\\.g" .cpp f1 "${f0}" )
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_BINARY_DIR}/${f1}
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_SOURCE_DIR}/${f0} ${CMAKE_BINARY_DIR}/${f0}
DEPENDS ${CMAKE_SOURCE_DIR}/${f0}
COMMENT "step 1")
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_BINARY_DIR}/generated/${f1}
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_BINARY_DIR}/${f1} ${CMAKE_BINARY_DIR}/generated/${f1}
DEPENDS ${CMAKE_BINARY_DIR}/${f1}
COMMENT "step 2")
add_library (mylib SHARED ${CMAKE_BINARY_DIR}/generated/${f1} )
This fails because add_library only understands target level
dependencies. add_custom_command only generates file level
dependencies. To make a target level dependency, you'd have to wrap
the last add_custom_command with an add_custom_target(blah DEPENDS
${CMAKE_BINARY_DIR}/generated/${f1}), then ADD_DEPENDENCIES(mylib
DEPENDS blah).
add_library would have understood the dependency just fine, if it were
not generated. Question: why couldn't add_library look for generated
files as well as non-generated files?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Custom build step
On Jan 21, 2008 6:16 AM, pepone. onrez <[EMAIL PROTECTED]> wrote:
>
> SET ( COPY_FILE cp -v )
Better: ${CMAKE_COMMAND} -E copy
Type cmake -E for details of OS portable commands.
Your example build fails on Cygwin with the same problem.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Custom build step
I'm going to take a wild guess that one of your variables is emitting extra quotes or open parentheses or something, such that the 2nd ADD_CUSTOM_COMMAND gratuitously disappears. Suggest you message() all your variables to see what they are, and also write a small test case that simulates the behavior you're trying to implement, without all the fancy extra logic. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Custom build step
On Jan 19, 2008 11:50 AM, pepone. onrez <[EMAIL PROTECTED]> wrote: > > Case 2 - i don`t see that Cmake generated any rule for the second commands. Did you grep all the files in the generated CMake tree? Perhaps they were output to a different file. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: add_custom_command dependencies in an auxiliary variable
On Jan 18, 2008 4:59 AM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > Brandon Van Every escreveu: > > > The dependencies of an add_custom_command are completely under your > > control anyways. You specify them. Why don't you just re-specify > > them in your command? > > It's a bit burdensome when the dependencies exceed the count of 10 or > 20. Ok, I could create them in a variable and use it, That's the usual way to do it. > but I'd like to mimic the gnu-make behavior. Why? Just because you know it? That's not a good reason to put it into CMake, if CMake can already accomplish the same thing. Commands like $^ are cryptic. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] adding static library when building static library
On Jan 18, 2008 1:50 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > Check the FAQ and the mailing list archives for more info on this issue. Sorry, the FAQ doesn't have any clear statement on the "static lib inside a static lib" issue. It does talk about so-called "convenience" libraries a bit. Your best resource is the mailing list archive. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] adding static library when building static library
On Jan 18, 2008 4:18 AM, Ramazan Girgin <[EMAIL PROTECTED]> wrote: > Hi all, > I am building static lib on windows.While building static lib i am using > external static library . With using cmake a couldn't add this static > library to my new static library. Some archivers such as AR cannot put a static library inside of a static library. I don't know whether MSVC archivers can. In any event, putting a static library inside of a static library is not portable, if it can be done anywhere. Check the FAQ and the mailing list archives for more info on this issue. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom_command dependencies in an auxiliary variable
On Jan 17, 2008 9:15 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > Hi, I wonder if it's possible to add_custom_command create a temporary > variable which contents are all dependencies of the custom command. This > could be used if one command shall contain all dependencies in its > command line. gnu make does that with $^ (i think). Something similar > with the output file name would be good (like $@ in gnu-make). The dependencies of an add_custom_command are completely under your control anyways. You specify them. Why don't you just re-specify them in your command? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom_command as target
On Jan 17, 2008 7:46 AM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote: > > That feature is, however, undocumented. Neither of the add_custom_* nor > the wiki has any mention of this or the possibility of add_custom_target > being able to take a custom command. Not true. add_custom_target says, "Dependencies listed with the DEPENDS argument may reference files and outputs of custom commands created with ADD_CUSTOM_COMMAND." Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom_command as target
On Jan 17, 2008 5:10 AM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote: > > Is there a way to create an add_custom_target that tracks dependencies? > Or an add_custom_command that will act as a target (without needlessly > being added to add_executable, etc). To get the effect of that, you wrap your add_custom_command with an add_custom_target. add_custom_command(OUTPUT blah ...) add_custom_target(mytarget DEPENDS blah ...) Admittedly this is inelegant, but it works. I have no idea how much work it would be to remove the distinction between file level and target level dependencies. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Jan 16, 2008 12:45 PM, Leopold Palomo-Avellaneda <[EMAIL PROTECTED]> wrote:
> A Dimecres 16 Gener 2008, Brandon Van Every va escriure:
> >
> > I wonder if this is the "Apple linker always prefers dynamic libs"
> > problem. Search the mailing list archives for that.
>
> I have this:
>
> add_library(${plugin} SHARED ${plugin_SRC} ${plugin_MOC_SRCS}
> ${plugin_UIS_H} ${plugin_SRCS} ${plugin_MOCS})
Well, if you're only using shared libs and no static libs, then I have
guessed wrongly about your problem.
> I don't know what are your reffering to search in the mailing list because I
> have done some search without any interesting result.
If you do have any static libs in your build, then try the keywords
"Apple shared static depreciated".
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Jan 16, 2008 12:16 PM, Leopold Palomo-Avellaneda <[EMAIL PROTECTED]> wrote: > > without any problem. Howeber, when I try to compile the project in OSX, I can > compile the libs, one exec but it fails with the first plugin. I have > isolated the problem in this: > > Linking CXX shared library libpluginregistrodeiva.dylib > Undefined symbols: > > I don't have any special consideration with the OSX platform (CMake is > wonderfull, isn't it?) but it fails in this. It seems that the compiler, when > link the plugin try to find anything that doesn't find (in linux it finds...) I wonder if this is the "Apple linker always prefers dynamic libs" problem. Search the mailing list archives for that. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name"CMakeLists.txt"! Introduction to "Common Build System"
On Jan 15, 2008 7:39 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > > Adding a layer written in cmake on top of cmake doesn't sound good IMO. I > think my main problem with autotools was that they were a set of tools, you > had to learn and know each of them, and if one of them failed I was > completely lost. Let's not go this route with cmake. I dislike Automake + Autoconf + Make + Libtool because they're fragile. So was Xlib / Xt / Motif back when I was doing that many years ago. Layers break easily, especially when the layers are not based on any kind of type safety, but are just layer upon layer of macro stuff. CMake is definitely better integrated than the Automake toolchain. I would encourage Martin to help with further CMake integrations and improvements. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to escape the $ dollar sign?
On Jan 15, 2008 7:04 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > On Tuesday 15 January 2008, Brandon Van Every wrote: > > > > I am still too lazy to write this up on > > http://www.cmake.org/Wiki/CMake:VariablesListsStrings > > I think because I perceive this wiki page as a bit buried in the shuffle. > > Oh, come on. > Can't you come up with a better excuse ? ;-) > It would be really nice if you could help with the wiki page. I did actually cut 'n' paste what I wrote onto the wiki. Docs from me are gonna suck like that for now. I figure a breadcrumb is better than nothing at all. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name"CMakeLists.txt"! Introduction to "Common Build System"
On Jan 15, 2008 2:54 PM, Andreas Pakulat <[EMAIL PROTECTED]> wrote: > > What I meant is, it looks like cbs wants to use CMake to replace the > "normal" package manager in a source-based distro. I still don't quite get it, perhaps because I have no practical experience preparing packages for distribution. I'll let Martin comment on the questions I've raised. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to escape the $ dollar sign?
On Jan 15, 2008 7:59 AM, Christopher Lang <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I am trying desperately to get the dollar sign ($) escaped properly in the
> following:
>
> ADD_CUSTOM_TARGET (read_potfiles_in ALL
> COMMAND grep -Ev '^\#|^\\[|^$' POTFILES.in > POTFILES.in.cmake
> WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
> )
>
> I searched everything but did not find a solution to get that dollar sign
> escaped.
>
> The result always looks like this:
>
> ...
> cd /home/chris/workspace/l2nl/po && grep -Ev '^#|^\[|^ POTFILES.in >
> POTFILES.in.cmake
>
> Escaping with signle or double \\ does not work.
Welcome to escape hell. :-) I can't comment on the special kind of
hell that is the COMMAND statement, whether VERBATIM or not. I
haven't been doing many of those lately. I can tell you all about $
escapes within regular expression strings though.
In a regex, outside of [] you need \\$
In a regex, inside of [] you do not need anything. [$] is fine.
In a non-regex string, in front of a curly bracket you need \${
set(blah "whatever but \${do_not_evaluate}")
In a regex string, in front of a curly bracket you need \\\${
string(REGEX REPLACE
".*whatever but \\\${do not evaluate}"
I am still too lazy to write this up on
http://www.cmake.org/Wiki/CMake:VariablesListsStrings
I think because I perceive this wiki page as a bit buried in the shuffle.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name"CMakeLists.txt"!
On Jan 15, 2008 5:15 AM, Martin Lutken <[EMAIL PROTECTED]> wrote: > > And can't see why you could nor set that option from the GUI also > Before generating the makefiles. One could, but as I posted previously, it would be a substantial amount of additional implementation work to do slickly, and it would have corresponding maintenance burdens. Are you volunteering? > I need it since I am trying to make a sort of "Common Build System" using > CMake as make generator. > The idea is to have a simple uniform way of building existing opensource SW. > I know CMake allready goes a long way in this goal, but I want to go further > by providing uniform CBS/CMake files for often used SW projects. Why not just work on any of CMake's deficiencies, in cooperation with the CMake community, and achieve your ends that way? > Also I want > it to be easy to create new buildfiles which works with the system so > hopefully > the project owners would keep them updated by themselves. That means people will have to learn a build tool. In principle, it could either be CMake or your build tool. But the CMake community is scads larger than any community you will personally be able to develop in the near future. Even given the CMake community's size and Kitware's commercial resources, we're recognizing the difficulty of teaching people to use a new build system. Documentation is a big issue. Do you have a better answer for how to document build tools? If you do, we'd love to see that energy applied to CMake. > Some projects might have their own CMake files allready (like KDE) and I am > not interrested in intefering with these - at least not at first. Are you sure you've correctly estimated the scale of work involved in switching build systems, when a project is that large? What's the largest build system you've worked on? Myself, I'm currently converting a 400MB codebase from GNU Autoconf + GMake to CMake. I can tell you it's daunting. If I am successful at getting these guys to switch, I'd be surprised if they switched again anytime soon. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Newbie Question: How to combine existing cmake project with other non-cmake project?
On Jan 15, 2008 4:34 AM, Tang Jacky <[EMAIL PROTECTED]> wrote: > Dear all, > > I have an open source library that does not come with cmake. > But I would like to use it as if it is a package so as to combine with my > own cmake project. > Is it easy or difficult? > What would people usually do to combine cmake with non-cmake libraries? ADD_CUSTOM_COMMAND is typically the drill. Like, you could just run whatever its native build is and feed it any needed arguments. That's pretty easy. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] feature idea: dependencies for modules
Yesterday I filed http://www.cmake.org/Bug/view.php?id=6243 "FindPerlLibs should search harder for Perl". I gave it priority "minor," meaning it wasn't burning a hole in anyone's pocket. It was summarily closed without comment, resolution "no change required." But I feel that's missing the point. FindPerlLibs works fine as long as you've used FindPerl previously. But where is it required that FindPerl be used previously? Several of the modules are inter-dependent in practice; they're meant to be used in conjunction, not standalone. But there is no explicit dependency requirement between them, and there is overlap of functionality which can lead to errors in corner cases. Also, modules aren't consistent about whether they include other modules. FindPNG has include(FindZLib). FindPerlLibs does not have include(FindPerl). How difficult would it be to have a dependency system for modules? Alternately, how about a policy requiring modules to include any modules that deliver the needed functionality, instead of gratuitously reinventing the wheel? I'm sure we agree that as far as the modules go, we'd like to maintain fewer wheels. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name"CMakeLists.txt"! Introduction to "Common Build System"
On Jan 15, 2008 11:46 AM, Andreas Pakulat <[EMAIL PROTECTED]> wrote: > On 15.01.08 11:37:12, Brandon Van Every wrote: > > I'm unclear. What is the strategic purpose of CBS? > > If I understood correctly, the purpose is to (at some point) build > foobar, including all deps completely with cbs. But is it a "higher level" CMake variant, or is it a completely new build tool that sees CMake as merely 1 of many possible output targets? > To me this totally > sounds like Gentoo with cmake files as "emerge" replacement. I'm reading http://linuxreviews.org/man/emerge/ and I don't understand how CMake could serve as an Emerge replacement. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name"CMakeLists.txt"! Introduction to "Common Build System"
On Jan 15, 2008 7:03 AM, Martin Lutken <[EMAIL PROTECTED]> wrote:
>
> Simple example from my actual codebase. CBS (Common Build System) makefiles
> for zlib and libpng, which depends on zlib (install stuff not included):
>
> --- z.cbs ---
> TARGET_DEFAULT_VERSION ( 1 2 3 )
> ADD_SOURCE_FILE ( adler32.c )
> ADD_SOURCE_FILE ( compress.c)
> ...
> ADD_SOURCE_FILE ( inffast.c )
Why do I want ADD_SOURCE_FILE? In CMake I just do:
SET(mysources adler32.c compress.c inffast.c)
ADD_LIBRARY(mysharedlib SHARED ${mysources})
ADD_LIBRARY(mystaticlib STATIC ${mysources})
>
> --- png.cbs ---
> TARGET_DEFAULT_VERSION ( 1 2 16 )
> ADD_DEPENDS_ON ( z )
Why do I want ADD_DEPENDS_ON? In CMake I just do:
TARGET_LINK_LIBRARIES(mysharedlib z)
TARGET_LINK_LIBRARIES(mystaticlib z)
>
> Note the ADD_DEPENDS_ON ( z ) for png. This single line takes care of all
> needed includes, linkdirs/libraries etc. thats neeeded to compile and link
> libpng.
>From your description, I don't understand what this is doing extra.
> In the (in time hopefully rare) cases where you depend on external libraries
> you use ADD_LINK_DIR, ADD_LINK_LIBRARY
CMake's TARGET_LINK_LIBRARIES doesn't care if you hand it external
link libraries or internal library target names. It just deals with
them. Why do you need a 2nd command?
> In case you need to add defines you can do
> ADD_DEFINE or ADD_PUBLIC_DEFINE
CMake has ADD_DEFINITIONS. What would ADD_PUBLIC_DEFINE do?
>
> --- Main configuration file ---
> Lastly I should mention some of the cool stuff you can do in the main
> configuration file, by this example from (again from my actual codebase):
>
> SET ( z_USE SYSTEM ) # Use system version (currently not Windows)
So you are implementing cross-compiling support? CMake CVS has that.
> SET ( png_USE BUILD) # Build from sources in this project
CMake can do this, but it has to be handled by the consumers of the
png library, not the png library itself.
if(use_myzlib)
TARGET_LINK_LIBRARY(mylib myzlib)
else(use_myzlib)
TAGET_LINK_LIBRARY(mylib z)
endif(use_myzlib)
> SET ( bz2_USE PREBUILT ) # Prebuilt (with CBS) from othter source tree.
I don't have a lot of experience with using CMake builds that wrap
other CMake builds. CMake does have mechanisms for 3rd party builds.
> SET ( z_LINK_TYPE STATIC ) # Build/use zlib static event though current
> default for project as a whole is to make shared libs/DLLs.
CMake already has that. ADD_LIBRARY(mylibname [SHARED | STATIC |
MODULE] blah blah blah) where the stuff in [ ] is optional.
> Well hope that gave you an impression of what it is.
I'm unclear. What is the strategic purpose of CBS?
Are you trying to do CMake projects, but at what you consider to be a
higher level of abstraction than CMake provides? If so, then it's
probably worth going over each of those features above individually.
Some of them, I think CMake does just fine already. Others, perhaps
you have a more elegant approach. But community buy-in is important
here. Nobody's looking for new things to learn, unless there are
clear benefits. One of the biggest detriments I see in adding new,
supposedly better ways of doing the same thing, is that CMake is
already woefully under-documented as is. So it really should do a
different or clearly better thing, not just a variation on the thing.
It's way easier for CMake developers to function as a community when
they're all speaking the same language.
Are you trying to make it possible to generate CMake projects, or
other build tool projects (SCons? Ant?) using a common build tool?
If so, that's already what CMake is trying to do. We don't want a
common build tool, we think we are the common build tool. We would
want a generator for SCons or Ant or whatever.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] running FIND_PROGRAM twice
On Jan 14, 2008 10:13 PM, David Cole <[EMAIL PROTECTED]> wrote: > And from the middle of the same text: > is created to store the result of this command. If the program is > found the result is stored in the variable and the search will not be > repeated unless the variable is cleared. If nothing is found, the > result will be -NOTFOUND, and the search will be attempted again > the next time FIND_PROGRAM is invoked with the same variable. The > > Score: pretty-clear 2 / not-so-clear 0 No, this is the unclear part. 2 different invocations of FIND_PROGRAM that share the same variable, but with different search parameters, are not the same search. I missed the clear example at the very very end of the FIND_PROGRAM entry. Presumably because it's separated from the above snippet by a lot of text. Putting the clear example right after the above snippet would help. Or a slight wordsmithing would help. I will provide that when I'm more alert. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] running FIND_PROGRAM twice
On Jan 14, 2008 9:14 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > > No, it is not correct. Once something is found, it can not be set to > NOTFOUND by another find command. If that were true, then cmake would > keep looking for things over and over. It is perfectly valid and > expected to call find_* more than once in a find module. The first one > that finds it will stop the searching. Ok. >This is all documented in the find_* commands. I don't think the docs are entirely clear about different invocations of FIND_PROGRAM that use the same variable. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Find*.cmake variable naming
On Jan 14, 2008 1:01 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote: > Some packages create a > *_LIBRARY, others *_LIBRARIES, Sometimes a library, like PNG, creates both, and the meanings are distinct. *_LIBRARY is the PNG library alone. *_LIBRARIES includes all of the link libraries you need to actually make PNG work, such as zlib. The only way I've found to use the Modules in practice, is to read their source code. There's not just a consistency problem, there's a documentation problem. Is there any way to automate the documentation of modules? Like require the use of functions that will spit out their input and output variables in a document format? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] running FIND_PROGRAM twice
On Jan 14, 2008 6:55 PM, Miguel A. Figueroa-Villanueva <[EMAIL PROTECTED]>
wrote:
>
> On Jan 14, 2008 7:18 PM, Brandon Van Every wrote:
> > I just filed bug http://cmake.org/Bug/view.php?id=6241 , "FindPerlLibs
> > should use FindPerl". My assumption is that if FIND_PROGRAM is run
> > twice with the same output variable (in this case PERL_EXECUTABLE),
> > the 2nd invocation will wipe out the value from the 1st invocation.
> > Is that a correct assumption?
>
> As I understand it, the second time will only execute if the first
> attempt is failed. That is, FIND_PROGRAM(output_var ...) sets
> output_var as a cache variable. If it is set to a XXX-NOTFOUND value
> then the second time it is invoked it will search again. If it is
> found the first time, then the second time it won't search for it
> (since it is found).
>
> This limitation has to do with not overiding values that the user sets
> in the GUI.
I should clarify. I mean FIND_PROGRAM is run twice in the same
invocation of CMakeLists.txt, with different parameters. Example:
FIND_PROGRAM(PERL_EXECUTABLE
perl
"C:/Perl/bin"
[HKEY_LOCAL_MACHINE\\SOFTWARE\\ActiveState\\ActivePerl\\804]/bin
[HKEY_LOCAL_MACHINE\\SOFTWARE\\ActiveState\\ActivePerl\\628]/bin
${CYGWIN_INSTALL_PATH}/bin
)
FIND_PROGRAM(PERL_EXECUTABLE perl )
Let's say the 1st FIND_PROGRAM finds a perl using HKEY. Will the 2nd
FIND_PROGRAM come up with NOTFOUND?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] running FIND_PROGRAM twice
I just filed bug http://cmake.org/Bug/view.php?id=6241 , "FindPerlLibs should use FindPerl". My assumption is that if FIND_PROGRAM is run twice with the same output variable (in this case PERL_EXECUTABLE), the 2nd invocation will wipe out the value from the 1st invocation. Is that a correct assumption? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name"CMakeLists.txt"!
On Jan 14, 2008 12:16 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > Brandon Van Every wrote: > > > > > Example: I have a legacy handwritten GMake client.mk that acquires the > > build tree from CVS before the main Autoconf generated Makefile is > > run. The tree is grabbed from CVS and built by typing "make -f > > client.mk". The simplest translation to a CMake system would be > > "cmake -f client.txt". Nobody would be doing a different drill, the > > client would perceive this as nice, to not have to learn much of > > anything different. Once the build tree has been acquired, we don't > > need client.mk anymore. The equivalent of Autoconf's Makefile should > > always be CMakeLists.txt. > > > > But that is not all the patch does. > > If you do cmake -f client.txt, then every add_subdirectory and subdirs > will now look for client.txt. I don't want that. I have trouble seeing sense in that, as I think system differences should be handled with if(APPLE) and so forth, not separate files. Martin could try to explain. > And, > cmake -f client.txt would not be the same thing as make -f client.mk, as > make -f client.mk would actually do a build. > For the cmake, one you > would have cmake -f client.txt, make (with no -f). Hm. I guess what *I* need is a way to output a different Makefile name. Oh well, back to the drawing board. I wonder what Autoconf does? Or I could translate client.mk to client.txt and make people type cmake -P client.txt. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name"CMakeLists.txt"!
On Jan 14, 2008 11:44 AM, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote: > > I don't specially like the idea of different names for CMakeLists.txt > and I don't see the use case, either. It makes sense for 'make' to > have a '-f' parameter because you have make, gmake, nmake, with > slightly or totally incompatible syntaxes but there is only one and > great CMake (and we can even ask for a minimum versior, of condition > execution of some parts depending on CMake's version). My perspective is that legacy Autoconf + GMake build systems do have multiple Makefiles in the same directory for various reasons. When converting such systems, it is easier to preserve their case uses. And politically, people coming from an Autoconf + GMake background will like "cmake -f blah.txt". It's familiar. It's not asking them to learn anything new. I advocate -f half for technical reasons, half for marketing reasons. > Anyway I think it'd be easy to integrate this feature in the Windows > GUI: instead of choosing a folder and automagically search for > CMakeLists.txt in it, let's make the user choose a file > (CMakeLists.txt or whatever the developer decided to call it). > Assuming instead of CMakeLists.txt a developer decided to call it > GreatCMakeLists.txt, cmake would then go and search for > GreatCMakeLists.txt instead of CMakeLists.txt in every SUBDIRS'ed or > ADD_DIRECTORY'ed directory. The slick way to do it, would be to scan all files in the directory, make an educated guess at which ones are CMake files, and offer a menu of files to choose from. If only CMakeLists.txt is available then no menu is generated. The guess would need some intelligence to discern between a main buildfile and sundry support scripts. Lack of a target *and* lack of an include might indicate that it's a support script, for instance. It would be substantial work to implement such a slick feature, it would require ongoing testing and maintenance, and it's overkill for the problem at hand. Adding -f to CMake, CCMake, and CMakeSetup is sufficient. It's simple to implement and requires almost no maintenance. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name"CMakeLists.txt"!
On Jan 14, 2008 9:01 AM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > > Brandon Van Every wrote: > > On Jan 13, 2008 10:04 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > >> Many people will run CMake from a GUI and will not be giving a > >> -f flag. With the patch there would be no way to build a project via > >> one of the GUI's if it required changing the name of the file. > > > > cmakesetup and ccmake would also need -f flags. Command line users > > and scripts could invoke -f flags just fine. Shortcuts on Windows can > > be made with -f flags in them if people want to present their builds > > that way. > > > >> If you > >> had two or more sets of cmake files in the same source tree, how would > >> that work? > > > > The same way it works now. Generally, such files are a case of "CMake > > invoking CMake." > > > > No offense Brandon, but I would like to here from Martin about how he > plans to use this feature. I imagine he will get around to answering for himself, but since I have my own case uses, I will explain mine. > I am not sure why you would want to have to > co-existing source trees. Example: I have a legacy handwritten GMake client.mk that acquires the build tree from CVS before the main Autoconf generated Makefile is run. The tree is grabbed from CVS and built by typing "make -f client.mk". The simplest translation to a CMake system would be "cmake -f client.txt". Nobody would be doing a different drill, the client would perceive this as nice, to not have to learn much of anything different. Once the build tree has been acquired, we don't need client.mk anymore. The equivalent of Autoconf's Makefile should always be CMakeLists.txt. This idiom of handwritten GMake files that provide isolated services to a large build tree is endemic to the large codebase I'm working on. "cmake -f weirdfile.txt" is a nice interface for that. Asking people to learn what CML_NAME means, when it isn't documented anywhere, is not a nice interface. I didn't think it would be unreasonable to expect CMake to use the same command line conventions as nearly every other tool out there. Who *doesn't* use -f for file? I'm surprised at the level of resistance you're offering for a minor feature that's standard design in hundreds of tools. > Also, I am not sure the same thing can't be > done with if and include. This requires the user to learn a CMake specific idiom, an example of which is not documented anywhere. Do enough of these inelegant workarounds, requiring people to hunt and peck for the answer, and people will rightly turn away from CMake over syntax issues, just not liking how it works, etc. Comprehensive chapter-oriented documentation can mitigate such problems, but it is better to simply do what everyone else does. > I also > don't see people invoking cmakesetup with any flags, it is a gui > program. Scripts may invoke it on behalf of people. People may invoke it if the README.TXT tells them to do so. As I said, in my current codebase the standard way of pulling the source tree from CVS and starting a build is "make -f client.mk". I think part of the disconnect here, is you're failing to recognize there's a whole breed of hackers out there that lives and dies by the command line. Sure they'll invoke a gui tool. By typing something on the command line. Please just throw the command line guys a bone. All the cool tools are doing it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name"CMakeLists.txt"!
On Jan 13, 2008 10:04 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > > Many people will run CMake from a GUI and will not be giving a > -f flag. With the patch there would be no way to build a project via > one of the GUI's if it required changing the name of the file. cmakesetup and ccmake would also need -f flags. Command line users and scripts could invoke -f flags just fine. Shortcuts on Windows can be made with -f flags in them if people want to present their builds that way. > If you > had two or more sets of cmake files in the same source tree, how would > that work? The same way it works now. Generally, such files are a case of "CMake invoking CMake." Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name"CMakeLists.txt"!
On Jan 13, 2008 4:23 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> Martin Lütken wrote:
> > That's great then. Do you know who to address in order to get the patch
> > into the CVS code ?
> >
>
> Actually, what about something like this:
>
> # CMakeLists.txt
> INCLUDE(${CMAKE_CURRENT_SOURCE_DIR}/${CML_NAME}")
>
> cmake /path/to/proj -DCML_NAME:STRING="mycmake1.txt"
> cmake /path/to/proj -DCML_NAME:STRING="mycmake2.txt"
>
>
> No changes needed to CMake at all
"Not needing to change CMake" may be useful for my own purposes, as I
have to ship with production versions of CMake, and I was planning to
wrap command line ugliness in a script anyways. But CMake is changed
all the time in order to better it. I don't see how "let's leave well
enough alone" is an argument in this case. In terms of command line
elegance, your solution leaves much to be desired over
cmake -f mycmake1.txt
cmake -f mycmake2.txt
Especially in the eyes of the Autoconf + GMake crowd, whom we'd like
to convert. Do you have a serious objection to CMake having a -f
flag?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name"CMakeLists.txt"!
On Jan 13, 2008 1:58 PM, Martin Lütken <[EMAIL PROTECTED]> wrote: > > > > Ok heres a new patch using '-f' as the option! Excellent, thanks! I could actually see a use for this, if it were available in a production version of CMake. The source tree I'm working on has multiple layers of Makefiles in the same directories. Many have names ending in *.mk. The main Makefile is generated by Autoconf, and the *.mk files seem to be used as non-Autoconf "subroutines". Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default name "CMakeLists.txt"!
On Jan 13, 2008 12:13 PM, Martin Lütken <[EMAIL PROTECTED]> wrote: > > It's a long time since I said I might do this feature. But with the > supplied > patch it's now possible to use the option '--cmakelists-file-name' to > specify > another filename to look for instead of 'CMakeLists.txt'. Is a short form single letter version of this command also available? I would recommend -f as it's parallel with Make. I also think --cmakelists-file-name is excessively verbose. --file would be sufficient, although you could retain the longer name also. Here's what Make does: -f FILE, --file=FILE, --makefile=FILE Read FILE as a makefile. I think it's important to respect these nuances / niceties / conventions for command line options. CMake is not a terribly command line oriented tool, but there's a lot of command line oriented people out there that we'd like to convert to CMake. So it would be good if we give them the kinds of things they expect, to the degree that it's easy for us to do so. I think in this case -f is quite easy. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] intltool and cmake?
On Jan 13, 2008 6:00 AM, Christopher Lang <[EMAIL PROTECTED]> wrote: > > Is there some example on how to integrate intltool & cmake? I don't know if there's anything about intltool specifically; Google + the mailing list archives might tell you. Generally one uses add_custom_command. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake dependency checking
On Jan 8, 2008 1:47 PM, Ajay Divekar <[EMAIL PROTECTED]> wrote: > Hi, > > I have the following directory structure > > ProjName >| >-> src > | > ->lib > | > ->app > > > if I execute cmake -DBUILD_TYPE=Debug at the app level I don't have any experience running CMake from subdirectories of a source tree. I'll let others comment on that. > then the linking > fails with missing lib. Obviously this because the lib is not compiled. Is > there any way for me to detect that when I do cmake in the app folder that > lib is not compiled and then compile for the linking to work. Do you have a TARGET_LINK_LIBRARIES command for app, so that lib will be linked? > BTW if I do > cmake @ the src level then everything works fine. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] getting the output directory in a cmake script
On Jan 8, 2008 2:46 PM, Jesse Corrington <[EMAIL PROTECTED]> wrote: > Is there any variable that stores the output directory where the project > files are generated. I need this information to create a post build step to > copy a file to the project root. Sure, CMAKE_BINARY_DIR and CMAKE_CURRENT_BINARY_DIR. http://www.cmake.org/Wiki/CMake_Useful_Variables You could also use PROJECT_BINARY_DIR or MyProjectName_BINARY_DIR. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] having ADD_CUSTOM_COMMAND call a macro
On Jan 7, 2008 7:07 PM, Jesse Corrington <[EMAIL PROTECTED]> wrote:
> Can the command for add_custom_command be a macro or does it need to be a
> built in cmake command? Thanks
It can't be a macro. It can't be any CMake command. The COMMAND has
to be some sort of shell command, like running a tool. You could
execute a CMake script containing CMake commands using "COMMAND
${CMAKE_COMMAND} -P myscript".
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On Jan 5, 2008 5:58 PM, Sebastien BARRE <[EMAIL PROTECTED]> wrote: > At 1/5/2008 09:24 PM, Jesper Eskilson wrote: > > >Those of you who haven't already read "Version Control and 'the > >80%'" should do so (http://blog.red-bean.com/sussman/?p=79) *before* > >forming your opinion on centralized version control. > > Interesting read, I found the 80/20 formulation kind of obnoxious. People who regularly swallow the intricacies of Java and C++ for a living, are incapable of swallowing DVCS concepts like "push" and "pull?" Baloney. It's a question of willingness to do so, or mandate to do so. When there's no will, and no mandate, then techies love to bitch and moan about any perceived inconvenience or learning curve. > especially the paragraph about: "In a nutshell: > with a centralized system, people are forced to collaborate and > review each other's work; in a decentralized system, the default > behavior is for each developer to privately fork the project.". I'm not impressed by any of the FUD I've heard about DVCS. There's a consistent theme of assuming that technology implies policy. In DVCS, it doesn't. The idea that developers privately fork projects "by default" is completely silly. You think I had time to maintain my own private version of Chicken Scheme? Heck no. Anybody who's really against DVCS should get some experience with it before passing judgment. > Anyway. Before flaming each others, please bear in mind that the > decision remains in our hands, at Kitware. Personally, I refute the case that there's anything deeply wrong with DVCS that should bar its use. Darcs never got in my way. Is there anything *compelling* about DVCS for the CMake community's needs? I don't know. At present, I don't care. I've yet to do any work in the CMake source pool; I just file bugs and edit the wiki. Mozilla is the study for Mercurial. It's still early days for them, they're in transition from CVS. I suggest watching them, to see what benefits they gain. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OpenSceneGraph Find Modules
On Jan 4, 2008 3:09 PM, Miguel A. Figueroa-Villanueva <[EMAIL PROTECTED]> wrote: > > I don't think this carries the bias you present. The idea is not to > force the user to have all packages installed if they are optional. > The module should only fail if a *required* package is not found. If > the SDL module was poorly designed in that sense, then it needs some > enhancements. Indeed the Chicken SDL package did need such enhancements. But they were not performed, because in the real world it's extra implementation labor to chase the changing components around. As you say, the problem is solvable in principle. In practice, whether it gets solved depends on the level of energy of the FindOSG maintainer. In this thread we've heard that he feels a bit, ah, overwhelmed by the scope of OSG, so I have my doubts that a monolithic FindOSG is going to function correctly over time. Perhaps the answer is for you and others to join forces with him so that it isn't 1 person being overwhelmed by the gruntwork. Chicken SDL packaging didn't improve much because the people who did tend to use it were Linuxers, and nobody wanted to be saddled with sole responsibility for the needed improvements. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On Jan 4, 2008 3:50 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > On 2008-01-04 07:17-0800 E. Wing wrote: > > > My 2 cents. > > > > Distributed [version control system] is the right way to go in my opinion. > > I don't completely agree. Centralized repositories have proved useful for > lots of software development projects (e.g., the 160,000+ free software > projects at SourceForge). Of course, centralized repos don't work very well > if projects (such as the Linux kernel) have huge numbers of active > developers, but most software projects (such as CMake) will never have more > than a handful of active developers, and for such projects a centralized > repository makes a lot of sense. Why? Other than it's what you're used to. When I was doing Chicken Scheme, we had very few people banging on the Darcs source repository, but nevertheless it was useful to our work. Typically we could just work past each other and not worry about merges. > Thus, it is probably a given that CMake > will always use a centralized repository. You haven't even begun to prove a "thus." What is so important about being centralized? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On Jan 4, 2008 10:17 AM, E. Wing <[EMAIL PROTECTED]> wrote: > > I think Linus pointed to some scalability problems in Monotone and I > think others have pointed to performance and memory usage problems > with Bazaar (OpenSolaris?, Mozilla?). I don't know what they tried before, but Mozilla is a Mercurial shop now. > I haven't seen much mention of > Darcs except for the 'dreaded exponential merge problem' and being > written in Haskell making it harder to port. My $0.02 is Darcs is easy to use. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OpenSceneGraph Find Modules
On Jan 4, 2008 2:09 PM, Luigi Calori <[EMAIL PROTECTED]> wrote: > > I would also prefer to have one single FindOpenSceneGraph that finds and > configure the different libraries that comprise OSG. Such an attitude can carry a strong Linux bias. I ran into that difficulty with Chicken Scheme when importing SDL modules. The SDL import was monolithic, pulling in lotsa 3rd party packages that are typically used with SDL but not strictly required. If any of the packages is missing the build breaks. I don't mean gracefully excludes an unavailable package, I mean it keels over and dies. This doesn't trouble Linux users because they typically press a few buttons and start downloading standardized, well-tested packages. Including everything and the kitchen sink isn't a big deal to a Linux user. But for a Windows user, there simply aren't colossal standard archives of libraries floating around. Every dependency has to be grabbed by hand. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake will not be able to correctly generate this project.
On Jan 3, 2008 12:31 PM, Gregory Anderson <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-01-03 at 12:22 -0500, Brandon Van Every wrote: > > On Jan 3, 2008 12:06 PM, Gregory Anderson <[EMAIL PROTECTED]> wrote: > > > I understand what you mean but fixing the path is a bit over my head. > > > How do I fix the path? > > > > Why don't you just reinstall the compiler? > > I did a few times. Try fooling with the GCC environment variables. http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html I think occasionally I've had to set C_INCLUDE_PATH and LIBRARY_PATH, but really, this stuff should already be set up for you "and just work" if you're using some kind of standard GCC package. Or did you build GCC from scratch or something? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake will not be able to correctly generate this project.
On Jan 3, 2008 12:06 PM, Gregory Anderson <[EMAIL PROTECTED]> wrote: > I understand what you mean but fixing the path is a bit over my head. > How do I fix the path? Why don't you just reinstall the compiler? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake on Linux + Playstation 3 (IBM Cell BE processor)
On Jan 2, 2008 10:00 AM, Christian Convey <[EMAIL PROTECTED]> wrote: > On Jan 2, 2008 9:15 AM, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > > On Monday 31 December 2007, Brandon Van Every wrote: > > > > > > I would assume that Linux tool ports just use the PowerPC core. > > > Getting the 8 SPE cores to be utilized is quite an extension of scope > > > and rather application specific. I would say you should handle those > > > with ADD_CUSTOM_COMMAND, > > > > Yes. > > The SPE cores are also programmed in C, aren't they ? > > GCC supports SPE code generation, presumably as just another back-end. > So I imagine that any language in the GCC suite works for SPEs. The problem is, the last I looked you had to go through elaborate dual linker dances to get PowerPC code and SPE code to talk to each other. I don't know if the tools have gotten better to pave that over, I haven't been tracking PS3 tool maturity. But this is what I meant when I said "quite an extension of scope." Expecting CMake to handle the SPE linker specifics may be asking for quite a lot, whereas I'm willing to bet that PowerPC only code works right now. Can you tell us what the actual PowerPC + SPE linking situation is nowadays? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake on Linux + Playstation 3 (IBM Cell BE processor)
On Dec 30, 2007 3:19 PM, Christian Convey <[EMAIL PROTECTED]> wrote: > > A Cell processor has one PowerPC core, plus 8 "SPE" cores (only 6 are > available on a Playstation 3). You need a different compiler for each > core type. > > Also, there are several different ways that all of that can be linked > together into a single program. > > I probably can coax Cmake into handling this, so I may have misspoken > when I asked about making CMake *capable* of building these programs. > I probably should have asked about making it support, out of the box, > the building of such programs using trivially simple CMakeLists.txt > files. I would assume that Linux tool ports just use the PowerPC core. Getting the 8 SPE cores to be utilized is quite an extension of scope and rather application specific. I would say you should handle those with ADD_CUSTOM_COMMAND, at least until you work out what a "standard" paradigm should look like. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Finding out what a preprocessor macro is defined as
On Dec 29, 2007 10:20 AM, Matt Williams <[EMAIL PROTECTED]> wrote: > > What I was hoping would be possible is for me to be able to run a cmake macro, > something like > INSPECT_CPP_MACRO(_BUILD_MODULE_ "../include/PlatformInformation.h" > BUILD_MODULE) which would compile and run the header file and put the value > of _BUILD_MODULE_ into BUILD_MODULE. You want either TRY_COMPILE or TRY_RUN. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007 4:54 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > > So, pattern/regex are only used to specify which files you want to > exclude or set permissions. The docs do not say that. [PERMISSIONS permissions ...] are optional. > Nothing is said about only allowing matching > files to be installed, so the current behaviour is correct, albeit not > ideal. No, it's bugged. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Install of pattern matched files
On Dec 28, 2007 4:55 PM, Mike Jackson <[EMAIL PROTECTED]> wrote: > > I used the following: > INSTALL(DIRECTORY src DESTINATION include/MXADataModel >REGEX ".*\\.h$" > ) > > and I get EVERY file located in the src directory, including all > subdirectories. By all files I mean EVERYTHING. CVS files, headers, > sources.. everything. I bet the CMake code that implements this has some unwarranted assumptions about what kind of regex is going to be passed. I bet the .* is matching against some list of files, and therefore matching any *list* that terminates with the pattern. Or it's just written wrong in some other way. Anyways it's a bug. Write a trivial reproducer and file it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007 4:33 PM, Mike Jackson <[EMAIL PROTECTED]> wrote: > > INSTALL(DIRECTORY src/ > DESTINATION include/MXADataModel > REGEX ".*\\.h$" > ) > > which I think should work. So what am I doing wrong? The regex is correct. What happens if you use "src" instead of "src/" ? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007 4:38 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > On Dec 28, 2007 2:51 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > > David Cole escreveu: > > > Can't you use "PATTERN" without the "EXCLUDE" to achieve this? > > > > Unfortunately no. Documentation doesn't say anything about it > > What version of CMake are you using? CMake 2.4.7 documentation says > plenty about this. INCLUDE(DIRECTORY ... PATTERN blah ...) should > work fine without an EXCLUDE Ok, now I get it. You're not using the INSTALL(DIRECTORY ...) signature. You're using the INSTALL(FILES ...) signature, and you're asking for PATTERN and PATTERN ... EXCLUDE to be available for that signature. Is that a good idea? Dunno, I don't have my brain cells wrapped around it at the moment. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007 2:51 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > David Cole escreveu: > > Can't you use "PATTERN" without the "EXCLUDE" to achieve this? > > Unfortunately no. Documentation doesn't say anything about it What version of CMake are you using? CMake 2.4.7 documentation says plenty about this. INCLUDE(DIRECTORY ... PATTERN blah ...) should work fine without an EXCLUDE >and I've already tried without success. If you're using CMake 2.4.7 and can reproduce that with a simple test case, it's a bug. File it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Install of pattern matched files
On Dec 28, 2007 1:33 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > Brandon Van Every escreveu: > > > "Too" cumbersome? Surely you jest. What's a long-winded list of > > patterns in terms of your development time? Two minutes tops? > > Oh well... thanks for teaching me another word: jest, and I'm not being > ironic. > > Back to business... imagine the following use case: a project mixes > headers and source files all inside the same directory, along with other > files. During install, I want to get all headers and copy to > /include/mylib. That's it. I think this is a very common > scenario. Do the REGEX and/or REGEX ... EXCLUDE signatures work? If so, then this is a low priority feature request. A PATTERN spares the programmer from having to learn how regexes work, but specifying these kinds of inclusions and exclusions with regexes is trivial. > > Sure, "it's easier." Sounds like a low priority feature request to > > me. File it in the bug tracker. > > I could implement it if I knew that it would be committed to cvs, that's > why I posted the idea here first. Can't imagine why it wouldn't be. You say it's easy to implement, and it's not controversial. > Happy new year, Indeed! Same. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Install of pattern matched files
On Dec 28, 2007 11:59 AM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > Hi, I've been using the install command and I'm missing a feature to > only install files matching a certain pattern. There's a way to exclude > files, but it's too cumbersome to specify all patterns that I don't want > to be installed, "Too" cumbersome? Surely you jest. What's a long-winded list of patterns in terms of your development time? Two minutes tops? > it's easier to specify patterns of files to be installed. Sure, "it's easier." Sounds like a low priority feature request to me. File it in the bug tracker. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: escaping!
On Dec 25, 2007 10:18 AM, Andrew Roark <[EMAIL PROTECTED]> wrote: > > On Dec 23, 2007 2:50 PM, Andrew Roark wrote: > > > What's a major project > > in SCons or some other build system that would be really clunky to do > > in CMake? > > I think the point the other poster in this thread and the posters in the Lua > discussions are making is that CMake is a good meta build system, not clunky > as you hint at, but that the _CMake script language_ is clunky and less > powerful than a real language. Clunky, fine. "Less powerful" with respect to build systems, has yet to be proven. Until someone proves it, with a concrete example, Kitware will never be convinced that any "better" language is needed. So I'm saying, quit talking about how Lua or some other language is supposed to be better, and find something that proves it would be better. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Merry Christmas
On Dec 24, 2007 8:47 AM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > I should add that this list has been very valuable in allowing me to > practice my English writing skills, maybe that's why I tend to write > more than I'm supposed to :) Always happy for a Merry Christmas! And all those other holidays if anyone wants to throw them in there. :-) Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Mac installation and cultural issues
On Dec 23, 2007 8:51 PM, Mike Jackson <[EMAIL PROTECTED]> wrote: > I was only hoping for the "option" to install somewhere > else than the default of /usr/bin. Installers on MacOS generally allow the choice of installation location, right? If they don't, I find that totally bizarre. In any event, if CMake uses an installer and doesn't allow a choice of where to install, that's totally bizarre. > The power uses who understand the > implications of moving cmake to another installation location will > understand we have to adjust our path. Those who do not understand > path issues probably don't care what is placed where, they just want > their app to work as Bill has stated. If checkboxes to set / not set the path are too complicated, then the installer can issue a warning message that the user needs to set the path manually. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: escaping!
On Dec 23, 2007 2:50 PM, Andrew Roark <[EMAIL PROTECTED]> wrote: > > But the idea of a more powerful programming language that drives the same > cmake logic is pretty interesting I encourage you to get beyond the "ideas" stage by seeking compelling exemplars in other build system communities. What's a major project in SCons or some other build system that would be really clunky to do in CMake? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On Dec 22, 2007 6:48 PM, Andreas Schneider <[EMAIL PROTECTED]> wrote: > Rodolfo Schulz de Lima wrote: > > That's great news. Since I've never been involved in a CVS -> SVN > > migration, I couldn't help so much with it. Also, excuse me for assuming > > you weren't using svn and trying to sell it to you :) > > Before you switch to svn please use git. It's much better than the pain of cvs > or svn. Mozilla is migrating to Mercurial. They rejected git; I forget why. It's early days for peer-to-peer source control, but based on my Darcs experience, in principle I'm a fan. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Mac installation and cultural issues
On Dec 22, 2007 6:20 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > In that world view, you'd add "first run invokes path configuration" > because it gives native MacOS bigots a warm squishy feeling. Then > they're singing the praises of CMake instead of bitching and moaning > about it. > > The first invocation doesn't have to be through a GUI either. ITon > the command line, either from CMake's installation directory or from > an absolute path. Damn this computer + GMail web interface! Somehow they consipre to send messages prematurely. That and Vista hard freezes every 3 days when I use the internet. Last occurence was 20 minutes ago. What a POS. Anyways... The first invocation doesn't have to be through a GUI either. It could be invoked on the command line, either from CMake's installation directory, or another directory using an absolute or relative path. The invoker could be a human being or a script. CMake could check a .path_configured file or some such in its installation directory to determine whether it has ever been configured. When invoked on the command line, it is best to issue a warning only. Nobody's looking for a forced interruption; the user might know exactly what they're doing and be deliberately using an absolute path. .path_configured doesn't mean that CMake is in a path. It means that the user has specified, either with an installer, a GUI interaction, or a command line option, that CMake is or isn't to be placed in some path. I do keep several hermetically sealed build environments on my Windows box, so it's perfectly reasonable not to have CMake in any path. Especially when I may have 3 versions of CMake on my system: the current release version, the latest CVS version, and a modified CVS version if I'm comparing against some Kitware patch. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Mac installation and cultural issues
On Dec 22, 2007 4:24 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > I still don't see the reason for the strong resistance to using an > installer program. Many Apple products including Xcode use one. Clearly a cultural issue. You're running afoul of "Mac native" culture as opposed to cross-platform development culture. I don't think platform bigots on any platform are to be taken too seriously. If they actually need to do cross-platform development, they will use whatever method actually works in practice. In that world view, you ship an installer, use it to configure the PATH options, and end the debate. That said, newbies may have a "bitch, moan, then accept" period to go through. The danger is they may instead go through "bitch, moan, then reject." They may not have sought out CMake, it may have semi-forced upon them. If they have a choice, i.e. if they're not going to get fired for rejecting CMake, then they may jolly well reject CMake on insubstantive grounds. For example, they might be a native MacOS developer at some company, and the Windows or other cross-platform group is floating CMake as a pilot project. The company may care about cross-platform development and CMake, but the individual employee may not. Enough grousing native MacOS developers might prevent the use of CMake. They might even prevent any cross-platform corporate strategy, if they have sufficient lame excuses / ammunition to force their point of view. So, I'm saying there's a motive to make CMake "palatable" to a native MacOS bigot. It's a way of converting such a person into a bona fide cross-platform developer (who does not care about such trivia anymore). Which in turn is a way of converting organizations. Particularly in larger organizations, there are many teams running around, competing with each other for the focus of the company. The ascendancy or decline of any given team may depend upon touchy feely issues, not necessarily core technical merit. In that world view, you'd add "first run invokes path configuration" because it gives native MacOS bigots a warm squishy feeling. Then they're singing the praises of CMake instead of bitching and moaning about it. The first invocation doesn't have to be through a GUI either. ITon the command line, either from CMake's installation directory or from an absolute path. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: call a configure command
On Dec 22, 2007 4:25 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > > Note, you don't have to do any of the above with add_custom_command. In > principle, you could also do those external builds with execute_process. > The difference, of course, is execute_process runs at CMake time so that > solves the issue we discussed before of wx-config from your build of > wxwidgets not being available at CMake time for the rest of your build. This will fail. execute_process runs in CMake's environment, not your build environment. Same reason we have to write try_compile and try_run instead of just doing execute_process. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] call a configure command
On Dec 22, 2007 1:48 PM, Steven Van Ingelgem <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> How can I call a configure command at compilation time? (so not at the
> "cmake ." call?)
Write a CMake script containing the configure command. Invoke it at
build time using ADD_CUSTOM_COMMAND COMMAND ${CMAKE_COMMAND} -P
myscript . Of course, this isn't going to configure anything. :-)
Are you just trying to perform text substitutions or something?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 4
On Dec 22, 2007 1:00 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > > So, how does it work? Where is mate installed? I have one simple > requirement: > > 1. you install cmake > 2. you can run it from the command line, or from the gui without > modifying additional things. > > I don't think that is too much to ask. If the user has to edit .profile > or something else, I don't think it is acceptable. I will get > complaints, "I installed cmake, and I run cmake and it says file not > found." Saying that cmake is for developers is not true. People use > CMake to build things like ParaView. They may not be developers at all, > they just want to build some open source tool. Having followed this thread, I realize I'm now confused about installation practices in the Apple universe. On Windows we run an installer. If we want CMake included in the path, whatever path we chose, we check a box. Do people not do this sort of thing on Macs? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] escaping!
On Dec 20, 2007 4:25 PM, Andrew Roark <[EMAIL PROTECTED]> wrote: > > By all means, if it can be done in CMake, then do it in CMake. > > But the CMake philosophy itself is in dispute with your argument. I don't need anything but CMake to do regexes. They aren't ideal regexes, but you can still get pretty far, and PCRE is coming. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ADD_SUBDIRECTORY
On Dec 20, 2007 11:47 AM, George Neill <[EMAIL PROTECTED]> wrote: > > I guess by issuing the ADD_SUBDIRECTORY() ( along with a PROJECT() ) I > am implicitly saying there's going to be a collection of stuff built > under this project. It makes sense (to me) CMake could automatically > generate a psuedo-target (synonomous with a "make all" for a > subproject I suppose). Having a subdirectory doesn't imply you want that stuff built as part of "make all." In fact there are explicit options to avoid this. A typical example is you've got some source code for sample projects, but you don't want the sample projects built by default. Test cases are another example. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Calling a dynamically created macro
On Dec 20, 2007 2:55 PM, Jesper Eskilson <[EMAIL PROTECTED]> wrote: > > Please let us know when you've implemented a webserver in CMake. ;-) It'll never happen. I can't stand the web. I'm a 3D / ASM / AI / game / build system guy. To me, the web has always been "the boring stuff that runs slowly." Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 7:32 PM, David Cole <[EMAIL PROTECTED]> wrote: > Where are these 10 lines? In the bug tracker, conspiciously above Bill's comments. They've been there for 6 months. http://www.cmake.org/Bug/view.php?id=5155 > On 12/19/07, Brandon Van Every < [EMAIL PROTECTED]> wrote: > > > > On Dec 19, 2007 4:24 PM, David Cole < [EMAIL PROTECTED]> wrote: > > > On 12/19/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > > > ...an easy feature to > > > > implement... > > > > > > So easy to implement that the attached patch was 0 bytes...? > > > > Bill's comments at http://www.cmake.org/Bug/view.php?id=5155 about > > "the difficulty" do not make any sense to me. It sounds like he tried > > to implement fullblown "convenience libraries." I just want to know > > where object files are turning up. I did it in 10 lines of CMake > > script and it worked everywhere that Chicken was built for many > > months. What's the problem? > > > > > > Cheers, > > Brandon Van Every > > > > ___ > > 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
Re: [CMake] Re: Calling a dynamically created macro
On Dec 19, 2007 7:05 PM, David Cole <[EMAIL PROTECTED]> wrote: > Now this thread is just plain cool. > > :-) Wait until I start building up a more advanced metaprogramming language from raw regular expressions. That idea occurred to me last night. I know regexes really well... can I keep going with it? If not, at least it'll teach me what regexes can't do, computationally speaking. But who knows, maybe anything that has PCRE could turn into a metaprogramming language translator. It would be really slick from a portability and maintenance standpoint. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Calling a dynamically created macro
On Dec 19, 2007 6:04 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2007 12:47 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> > Brandon Van Every escreveu:
> >
> > > You could use a macro to generate a CMake script containing a macro,
> > > and then call that script. :-)
> >
> > Nice... :)
>
> In fact, it turns out you can use an include() to cause it to exist at
> the point you create the macro. A downside is the number of escapes
> you have to put into your meta-macro, such as \\\${myvar}.
If you don't need to invent arbitrarily complicated macros on the fly,
but just want to substitute some hardcoded values like the macro name,
running configure_file on a "template" macro file might be more
convenient. You wouldn't need funky escapes in a pre-written template
macro file.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ADD_SUBDIRECTORY
On Dec 19, 2007 4:44 PM, George Neill <[EMAIL PROTECTED]> wrote: > Hi CMakers, > > I have a simple example. I am curious why CMake doesn't > automatically build a psuedo-target when an ADD_SUBDIRECTORY is > issued? Because having a subdirectory doesn't imply that you're going to do anything there. It could just be an intermediate part of your source tree. Perhaps the CMakeLists.txt in that subdirectory merely contains more ADD_SUBDIRECTORY commands. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Calling a dynamically created macro
On Dec 19, 2007 12:47 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every escreveu:
>
> > You could use a macro to generate a CMake script containing a macro,
> > and then call that script. :-)
>
> Nice... :)
In fact, it turns out you can use an include() to cause it to exist at
the point you create the macro. A downside is the number of escapes
you have to put into your meta-macro, such as \\\${myvar}.
# could figure out whether endline is \n or \r\n for this OS
#set(endline "\n")
macro(makemacro macro_name) #macro_args ... macro_body
if(${ARGC} GREATER 2)
set(macro_args ${ARGN})
list(REMOVE_AT macro_args -1)
else(${ARGC} GREATER 2)
set(macro_args)
endif(${ARGC} GREATER 2)
if(${ARGC} GREATER 1)
set(argn_list ${ARGN})
list(GET argn_list -1 macro_body)
#message("macro body")
#message("${macro_body}")
else(${ARGC} GREATER 1)
set(macro_body)
endif(${ARGC} GREATER 1)
set(mstart "macro(${macro_name} ${macro_args})")
set(mend "endmacro(${macro_name})")
set(macro_file ${CMAKE_CURRENT_BINARY_DIR}/macro_${macro_name}.cmake)
#file(REMOVE ${macro_file})
if(EXISTS ${macro_file})
message("can't create ${mstart}")
message(FATAL_ERROR "${macro_file} already exists")
endif(EXISTS ${macro_file})
file(WRITE ${macro_file}
"${mstart}
${macro_body}
${mend}
")
include(${macro_file})
file(REMOVE ${macro_file})
endmacro(makemacro)
makemacro(meta string_const
" message(\"\\\${string_const}\")
")
meta("I can do what I want")
C:\devel\src\cbugs\makemacro>cmake -P makemacro.cmake
I can do what I want
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 19, 2007 1:44 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote: > > The solution I proposed solve these problems. If I write a script where > my cmake matches ^ to line endings, I'd expect this behavior, and my > script would work correctly as I, the developer, expected. What if you were translating from a legacy build system, you expected regexes to work pretty much like they do in every other language or system, it turns out they don't, and you didn't test for the corner cases because the legacy build system had a truly vast number of option permutations to trundle through? You might not hit the bug for a year. Whereas if the behavior had been "fixed" in later versions of CMake, you'd never have a problem. The big flaw in your agenda is you assume the developer knows what's going on, and totally understands the behavioral implications of any given CMake version number. In the real world it ain't so. That's why we need specific "opt in" options. If the developer said set_property(GLOBAL PROPERTIES CMAKE_MATCH_LINE_ENDINGS TRUE) then we know exactly what the developer intended and what to provide. Do you expect me to track all the behavioral differences by version number as CMake evolves? You noticed the number of people asking "which version of CMake did behavior X first appear in?" People have no clue. > >> If you turn something into default behavior, it'll break backward > >> compatibility. > > > > Eventually that's acceptable. > > Maybe not... a solution the maintains complete backward compatibility > should do it always to cope with legacy scripts. At least I think that's > cool. CMake has broken things before and will break things again. It all depends on how ancient things get. > > That's what include(Modern) is for. You can look inside of > > include(Modern) to see what it specifies. That's what better > > documentation is for. > > So maybe one day we will have include(Modern), then include(Moderner), > then include(Modernerst), then include(ÜberModern),... Its contents would have to be managed according to some policy or mission statement. This is no different than deciding what's a bug, what's a feature, what to put in a new version of CMake, what to leave out. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 4:24 PM, David Cole <[EMAIL PROTECTED]> wrote: > On 12/19/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > ...an easy feature to > > implement... > > So easy to implement that the attached patch was 0 bytes...? Bill's comments at http://www.cmake.org/Bug/view.php?id=5155 about "the difficulty" do not make any sense to me. It sounds like he tried to implement fullblown "convenience libraries." I just want to know where object files are turning up. I did it in 10 lines of CMake script and it worked everywhere that Chicken was built for many months. What's the problem? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 3:52 PM, David Cole <[EMAIL PROTECTED]> wrote: > Compilation time is only multiplied if you are specifying the same source > file in multiple targets. If you are seeing a 2x difference, then you must > have *all* of your source files listed twice. Shouldn't this only be for a > few of your source files at most? How would you know? It would depend entirely upon his hierarchy of source file abstractions. A static library cannot include another static library. That severely limits abstractions. That's why you guys end up talking about silliness like "one static lib per exe." There are no available abstractions to do otherwise. I didn't want to be forced to recompile PCRE 6 times for all its different consumers, when I knew jolly well they were all supposed to receive exactly the same objects, no flag variations whatsoever. I didn't want the end user to be aware of PCRE, it was an implementation detail of Chicken that they should never have to think about. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 3:41 PM, David Cole <[EMAIL PROTECTED]> wrote: > One other very good reason, too: > Same target may have two source files of the exact same name, but they exist > in different directories (Abc/Object.cxx and Def/Object.cxx). In that case, > the object files will be further hidden in subdirectories to avoid two files > in the "object files directory" from having a name collision. If we had a standard way of finding the location of object files, this wouldn't be an issue as the directory name would be part of what's returned. You guys sure argue a lot about an easy feature to implement. Where's the harm in making it easy for the user to find the object files? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 11:28 AM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > > Maybe I am missing something, but why not create a static library and > share it with the executables? The end product may not be an executable, it may be a static library. A static library cannot include another static library. I came up with a hack to find CMake's objects and reuse them, so that the user of a static library would not have to add additional link flags. In particular, I wanted the user to be able to specify -lchicken, and not have to specify -lchicken -lpcre. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 11:08 AM, Joel Schaerer <[EMAIL PROTECTED]> wrote: > Thanks a lot. This is a real issue since compiling everything two or ten times > just for the sake of it is *not* efficient. We are currently considering > switching back to makefiles and a custom VS project because of this. I'd be happy to see your comments on this in the bug report. It's not going to get action unless someone other than myself lights a match under the issue. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Calling a dynamically created macro
On Dec 18, 2007 9:50 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > Is there a way to call a dynamically created macro name? You could use a macro to generate a CMake script containing a macro, and then call that script. :-) Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
On Dec 19, 2007 9:09 AM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > However, this has been discussed many times > over the years, and I still don't think a good solution has been found. Worse Is Better. From a marketing standpoint, this issue could have been solved a long time ago. You want people coming from the Autoconf world to get enough of a warm squishy feeling that they stick with CMake. Over time they learn how to use CMake properly, using CMakeSetup / CCMake, and forget their command line ways. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Lua performance
On Dec 19, 2007 1:52 AM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote: > > Sure, lua runs 10 times faster than the cmake language does, but that's > a different story. So what's the story? Can you substantiate that? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 10:47 AM, Joël Schaerer <[EMAIL PROTECTED]> wrote: > I have read this FAQ entry, but it doesn't seem to adress my issue at all... Did you read http://www.cmake.org/Bug/view.php?id=5155 ? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 7:34 AM, Joël Schaerer <[EMAIL PROTECTED]> wrote: > Hi all, > > is there anything new regarding this issue : > http://www.cmake.org/pipermail/cmake/2005-September/007271.html http://www.cmake.org/Wiki/CMake_FAQ#Does_that_mean_I_have_to_build_all_my_library_objects_twice.2C_once_for_shared_and_once_for_static.3F.21__I_don.27t_like_that.21 Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 8:32 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > Brandon Van Every escreveu: > > >> We would have to guarantee that version 2.4.7 executes correctly every > >> script made up till now. > > > > I don't see how we could. > > Well, Kitware has always been concerned with backward compatibility, so > every script out there would work with cmake-2.4.7. I'd also throw > cmake-cvs in the mix, since they still fight hard to maintain backward > compatibility. > > > The author may have been completely unaware of the potential of the > > error condition, having never seen the circumstances in which the > > error occurs. We don't know that "I wrote this using 2.4.7" means "I > > want it frozen for 2.4.7." Let's even say, for sake of argument, that > > you provided an interface for the author to state exactly that. > > version_freeze(2.4.7). It still may not be a good idea, because the > > author may not have full knowledge of the consequences of his > > decision. > > But if you correct the behaviour, the script wouldn't work as expected. > Is this a good thing? We don't want things to work as expected, we want things to work correctly. > Can you create an example of such error condition? What if VERBATIM behavior becomes easier to work with? Or quoting behavior in corner cases? What if macros no longer consume double the number of escapes? What if ^ and $ start matching line endings instead of the beginning and end of the file? We don't know how much the author knew about the code he was writing. It would be better to handle variations of behavior according to the specific feature, rather than by version number, so that the author can tell us what he wanted. set_property(GLOBAL PROPERTIES CMAKE_MATCH_LINE_ENDINGS TRUE). > >> I don't think we need to tie "disruptive" features to version numbers. > > I want set_property(GLOBAL PROPERTIES CMAKE_REQUIRE_BOOL TRUE). I'm > > willing to wait a loong time for it to become a default CMake > > behavior. I think include(Modern) is a good idea in principle, for > > people who want to use a well-defined collection of forward looking > > behaviors. The idea may need refinement in practice, but the general > > idea is "opt in." Not "tie my hands." > > If you turn something into default behavior, it'll break backward > compatibility. Eventually that's acceptable. > And as time goes by, the amount of disruptive features > tends to grow. In the future to write a script I would have to write lot > of set_property(GLOBAL PROPERTIES CMAKE_REQUIRE...)... That's what include(Modern) is for. You can look inside of include(Modern) to see what it specifies. That's what better documentation is for. > It'd be better to > specify the version of cmake I'm working on and that's it. No it isn't. It doesn't identify the specific behaviors that have changed. > PS: feel free to correct any English mistakes I make. I won't learn if I > keep writing wrongly. Haven't noticed any. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 7:48 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > Alexander Neundorf escreveu: > > > This is wrong. This would mean that the old buggy behaviour in the code > > would > > have to stay in an if(version==2.4.7) block, and next to it the fixed block > > for newer versions. This is not maintainable. > > Well, isn't it what is happening with SUBDIRS vs. ADD_SUBDIRECTORY? How > this problem is being handled now? They're non-conflicting commands. The reason there's a problem is because they do very similar things but have different behavior. Users don't know any better so they do stuff with SUBDIRS. CMake 2.6.0 will list SUBDIRS in the depreciated section of the documentation. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 7:39 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > On Wednesday 19 December 2007, Rodolfo Lima wrote: > > > > I think that this solution would let Kitware add disruptive features > > with ease. > > This is wrong. This would mean that the old buggy behaviour in the code would > have to stay in an if(version==2.4.7) block, and next to it the fixed block > for newer versions. This is not maintainable. The maintainability would depend on the codebase. In some cases it would be easy, in others hard or impossible. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 7:31 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > Brandon Van Every escreveu: > >> That would be easy to cope with, no version specification = 2.4.7. > > > > If it actually works under 2.4.7 and doesn't need some other earlier > > version to function with. > > We would have to guarantee that version 2.4.7 executes correctly every > script made up till now. I don't see how we could. > > What if 2.4.7 ships with an arguably bad behavior, 2.4.8 fixes it, and > > my code is stuck with the 2.4.7 behavior because you didn't think > > anyone was ever supposed to avail themselves of improvements? > > That would be a big mess, but if the script *works*, even with bad > behavior, so be it. Maybe a warning should be emitted. The point is to > guarantee that the script the author made will work the same way he > intended, forever. It would be wrong if we changed the behavior the > author relied upon. The author may have been completely unaware of the potential of the error condition, having never seen the circumstances in which the error occurs. We don't know that "I wrote this using 2.4.7" means "I want it frozen for 2.4.7." Let's even say, for sake of argument, that you provided an interface for the author to state exactly that. version_freeze(2.4.7). It still may not be a good idea, because the author may not have full knowledge of the consequences of his decision. > I think that this solution would let Kitware add disruptive features > with ease. I don't think we need to tie "disruptive" features to version numbers. I want set_property(GLOBAL PROPERTIES CMAKE_REQUIRE_BOOL TRUE). I'm willing to wait a loong time for it to become a default CMake behavior. I think include(Modern) is a good idea in principle, for people who want to use a well-defined collection of forward looking behaviors. The idea may need refinement in practice, but the general idea is "opt in." Not "tie my hands." Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 6:43 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > Brandon Van Every escreveu: > > > But old scripts don't do that. One could do it for new scripts, but > > old scripts are what they are. Also, I don't necessarily want my > > script to be limited to CMake's behavior when I wrote it. > > That would be easy to cope with, no version specification = 2.4.7. If it actually works under 2.4.7 and doesn't need some other earlier version to function with. > And when you write a script, you would set the version to the current > version you're testing on. That would guarantee that this script will > ALWAYS work, no matter how cmake evolves. That's a good deal. What if 2.4.7 ships with an arguably bad behavior, 2.4.8 fixes it, and my code is stuck with the 2.4.7 behavior because you didn't think anyone was ever supposed to avail themselves of improvements? Cheers, Brandon ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 3:31 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote: > > But let's imagine that each feature has a minimum and possibly a maximum > cmake version where it's supported. So, if we specify in the script > which cmake version it is written to, But old scripts don't do that. One could do it for new scripts, but old scripts are what they are. Also, I don't necessarily want my script to be limited to CMake's behavior when I wrote it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] attempt to summarize
On Dec 18, 2007 4:08 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
>
> Missing:
> -ant: I think having an ant generator might be nice [...]
> It would also mean that CMake
> generates ("modern") XML files instead of ("old fashioned") Makefiles.
> -any others ?
If someone wants to do Ant, and they're really really motivated, then
they'll do Ant and I imagine CMake won't refuse their work.
However, I'm not presently convinced that Ant, Maven 2, or XML-based
build systems in general, are strategic. Although widely deployed,
there are some indications that the Java universe doesn't think
they're so hot after all. Wiser people have recognized that you
really do need conditional logic to do a build system, and that
hacking conditionals within the constraints of XML is extremely
clunky. This is the origin of JRake, Raven, and Groovy. I would
watch these tools, and similar, to see what kind of progress they
make. If we had a crystal ball, we'd really like to know who's going
to win the "how do you script Java?" wars. There are many offerings.
No clear winners.
In the same vein I'm thinking it's premature to commit to Lua. It may
be more important to commit to whatever the Java universe commits to.
Consider, for example, that embedding Ruby and shipping with possibly
4MB of source file bloat, would be acceptable if it emerged as the
clear slam dunk de facto standard for building Java apps. But that
wouldn't be for several years yet, if ever. I can't tell whether
Raven is a really important project, or just 2 guys getting a lot of
notoriety because nobody else is doing anything. Their mailing list
certainly has a lot of crickets chirping. At some point next year I
imagine we'll see what they're capable of.
The performance differences between Python, Ruby, and Lua may also
change in the next few years. People have worked on speeding Python
and Ruby up. Maybe someone will finally succeed?
I think migration technologies in general are worth investing in.
This is a more technologically advanced proposition than hanging one's
hat on Python, Ruby, or Lua and hoping that OO will confer competitive
advantages. I think the money is tied up in moving from old build
systems to new build systems, and making that job less labor
intensive. I don't have any thoughts yet on what an ideal migration
technology would look like. When I look at the Tiobe list of popular
languages http://www.tiobe.com/tpci.htm , none of the top 20 languages
are interesting as a basis for migration technology. With the
possible exception of Lisp/Scheme. This says to me that industry
doesn't know how to metaprogram. I do follow the Microsoft Research
offerings a little bit. Perhaps they will push one of their languages
into popularity.
I think superior documentation and tutorial technologies are part of
superior migration technologies. Many things could be done here.
Often not the sort of thing that techies like to do though.
>
> CMake features
>
>
> better regexps wouldn't hurt
Related: introduce bool type, remove boolean pollution from strings
(Y, N, YES, NO, ON, OFF). Grabbing small character sequences to mean
TRUE or FALSE is an unclean practice; I've demonstrated the errors it
can introduce. NOTFOUND is a large character sequence and not so
problematic.
General mechanism for future-looking behaviors, so that we're not
forever stuck with the argument "it'll break backwards compatibility.
> I could create a wiki page "TODO items" so interested people may pick
> something to work on.
Not sure that helps. Anything I suggested, I can implement. Others
might get to it faster, and choose to run with it, but if no one else
cares, I certainly will. I haven't met a lot of open source people
who will just work on any old thing. Maybe such people exist, and
maybe it's possible to marshal them into various things. But I think
more is needed than a TODO list, to accomplish that. Someone has to
actually lead on any given feature. This is why projects often use a
bug tracker to organize this kind of stuff. The problem with a bug
tracker is it doesn't tell you at-a-glance what people are working on.
What we really need is a way to dump that information out of the bug
tracker and display it on a webpage. Would this be as simple as
defining a particular Mantis view, and then making a wiki page about
using Mantis to examine that view?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Using FILE(REMOVE_RECURSE ...) on clean targets
On Dec 18, 2007 2:33 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote: > > I think you misunderstood what I meant. Then we do 'make clear', the > CMakeFiles/project.dir/cmake_clean.cmake gets executed. That's where the > FILE(REMOVE ...) command I'm talking about resides. This is created by > cmake during build configuration, but IMHO it should be > FILE(REMOVE_RECURSE ...) so that 'make clean' removes any directories > specified with CMAKE_ADDITIONAL_CLEAN_FILES property. Sounds like a bug. File a reproducer in the bug tracker. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 2:36 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote: > Brandon Van Every wrote: > > >> Hint: there's already the > >> cmake_minimum_required command (at least in cmake-cvs, that is)... > > > > cmake_minimum_required has been around for awhile now. It does not > > solve the problem. > > Why is it so? If I'm using, say, 2.10.0 stuff, I'd issue a > cmake_minimum_required(VERSION 2.10.0 FATAL_ERROR) and cmake would > behave without having to cope with backwards compatibilities. Let's say really old code does cmake_minimum_required(VERSION 2.2.0 FATAL_ERROR). CMake 2.6.0 meets that minimum requirement. It should run the old code correctly, unless there's a really really good reason to break backwards compatibility. CMake 2.6.0 isn't going to have CMAKE_REQUIRE_BOOL, or any such newfangled change, as default behavior. It would break old code. cmake_minimum_required is a *minimum* requirement, not an exact requirement or a maximal requirement. We have to get from 2.6.0 to 2.8.0 to 2.10.0. Sure, in the distant future, CMAKE_REQUIRE_BOOL could be default behavior and cmake_minimum_required(VERSION 2.10.0 FATAL_ERROR) would be sufficient to enforce it. But we're not there yet. We'll have to go through 1, maybe 2 generations of CMake before enough people have voted with their feet to retire the legacy behavior. 2 generations before CMake is allowed to break ancient "Y" "N" "Yes" "No" "ON' "OFF" code with impunity. And that's assuming people actually like bool() and adopt it wholesale. For any given feature, it's quite possible that the community will not accept it wholesale. In the worst case, we could be selecting CMAKE_REQUIRE_BOOL as an option indefinitely. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Using FILE(REMOVE_RECURSE ...) on clean targets
On Dec 18, 2007 1:55 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
>
> > I thought REMOVE_RECURSE was a straightforward unconditional nuke. I
> > don't see that cleanliness has anything to do with it.
>
> Well, if I want to clean (remove) a directory, I'd expect it to be
> removed regardless if it contains subdirectories.
FILE commands are performed at configuration time. They don't have
any relevance to actions performed at build time. Not unless you've
wrapped them up in a CMake script and issued an ADD_CUSTOM_COMMAND of
the form COMMAND ${CMAKE_COMMAND} -P myscript.cmake.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 1:44 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote: > Brandon Van Every wrote: > > > How about include(ForwardsCompatibility). That would make the intent > > really clear. > > IMHO a better solution would be to specify which CMAKE version is > expected to parse the CMakeFiles.txt. Well, maybe "ForwardsCompatibility" doesn't make the intent as clear as I thought. The actual intent is for different CMake behaviors to exist side-by-side. Default behavior is whatever CMake currently does; usually pretty conservative in the interest of backwards compatibility. But the user could select a behavior like set_properties(GLOBAL PROPERTIES CMAKE_REQUIRE_BOOL TRUE). That could be available in CMake 2.6.1, for instance. "Parse it like 2.6.1" doesn't mean anything; it could be the default parsing or the CMAKE_REQUIRE_BOOL parsing. You'd need to have an option like CMAKE_REQUIRE_BOOL being used for a long time. You couldn't make it the default until CMake 2.8.0 or 2.10.0 or some such, after lots of people have voted with their feet and the old behavior is clearly legacy. > Hint: there's already the > cmake_minimum_required command (at least in cmake-cvs, that is)... cmake_minimum_required has been around for awhile now. It does not solve the problem. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using FILE(REMOVE_RECURSE ...) on clean targets
On Dec 18, 2007 1:38 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote: > What are the implications of using FILE(REMOVE_RECURSE ...) instead of > FILE(REMOVE ...) on clean targets? I thought REMOVE_RECURSE was a straightforward unconditional nuke. I don't see that cleanliness has anything to do with it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] General modernization facility
On Dec 18, 2007 1:06 PM, James Bigler <[EMAIL PROTECTED]> wrote: > Brandon Van Every wrote: > > > > include(Modern) would turn on improvements that are > > clearly desirable but break backwards compatibility. > > > > Heh, I wonder if in some instances the opposite would be needed, > > include(Ancient) ! :-) Something that either suppresses appeals to > > modernity, or warns vehemently against them. > > Perhaps this could be enforced by CMAKE_BACKWARDS_COMPATIBILITY variable. > If you supply a sufficiently modern version of cmake, then deprecated things > will turn on > warnings/errors. If you set the version lower, then features that were not > deprecated at > that version wouldn't issue warnings. How about include(ForwardsCompatibility). That would make the intent really clear. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
