RE: [CMake] UseLATEX make clean
I assume that proposal.latex is either the man LaTeX document or one if the INPUTS passed to ADD_LATEX_DOCUMENT. In this case, that file is copied over to the build directory as part of the build process. CMake considers the file in the binary directory a "built" file, and thus it is appropriate to delete it with "make clean". If you were to run make again, the file should be copied over (or configured) again. If you are saying that the file is being deleted from the source directory, then that would be a bug. -Ken > -Original Message- > From: [EMAIL PROTECTED] [mailto:cmake- > [EMAIL PROTECTED] On Behalf Of Marco Yuen > Sent: Tuesday, February 19, 2008 1:00 PM > To: cmake@cmake.org > Subject: [CMake] UseLATEX make clean > > Hi all, > > On one of my projects, I am using the UseLATEX macros to build a latex > document. But the problem is when I type `make clean', it removes my > *.latex document. I did a simple grep and found out that the file, > CMakeFiles/dvi.dir/cmake_clean.cmake, contains the following: > > FILE(REMOVE > "CMakeFiles/dvi" > "./proposal.latex" > ) > > Any idea why it tries to remove the latex file? > > Thanks, > Marco > > ___ > 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] GLOB segmentation fault
On Tuesday 19 February 2008, pepone.onrez wrote: > Your example also works well for me and don't reproduce the bug. > > I attach a file with my example Yes, crashes with 2.4.6, works with cvs. Can you please check with 2.4.8 ? Available e.g. from the cmake download page. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GLOB segmentation fault
Your example also works well for me and don't reproduce the bug. I attach a file with my example On Feb 19, 2008 7:24 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > Hi, > > On Tuesday 19 February 2008, pepone.onrez wrote: > > [EMAIL PROTECTED] ~/kk/cmake-glob-bug $ cat CMakeLists.txt > > FILE (GLOB TESTS ./test/ *.cpp) > > > > ls -liha test/ > > total 0 > > 3635635 drwxr-xr-x 3 pepone pepone 72 2008-02-19 04:56 . > > 998787 drwxr-xr-x 4 pepone pepone 160 2008-02-19 04:52 .. > > 3635679 drwxr-xr-x 2 pepone pepone 48 2008-02-19 04:56 .svn > > > > > > Problem seems to appear when test contains directories files that`s > begin > > with '.' > > I still can't reproduce it, my test project is attached. It works both > with > cmake 2.4.6 (from slackware) and cmake cvs. > > Does it crash for you ? > > Alex > > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > cmake-glob-bug.tar.bz2 Description: BZip2 compressed data ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] UseLATEX make clean
Hi all, On one of my projects, I am using the UseLATEX macros to build a latex document. But the problem is when I type `make clean', it removes my *.latex document. I did a simple grep and found out that the file, CMakeFiles/dvi.dir/cmake_clean.cmake, contains the following: FILE(REMOVE "CMakeFiles/dvi" "./proposal.latex" ) Any idea why it tries to remove the latex file? Thanks, Marco ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_dependencies question
Alan,
thanks for the help. You are right that your approach works without
debug/optimized. Unfortunately, even though
TARGET_LINK_LIBRARIES(blendmaterials fem)
works, this doesn't (in a debug build tree):
TARGET_LINK_LIBRARIES(blendmaterials femd)
The former is also incorrect for a debug build tree, because libfem.a
is not even built in that tree.
I suspect this has to do with my (inproper?) use of
CMAKE_DEBUG_POSTFIX. I'll try to set up a hello world cmake file,
thanks for the suggestion!
--nico
On Feb 19, 2008 1:23 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
>
> On 2008-02-19 11:38-0500 Nico Galoppo wrote:
>
> > Hi,
> >
> > I'm trying to get a 'demo' program inside my project tree to link in
> > (and depend on) one of the built libraries from the same project tree.
> > I'm having trouble getting the build process for the demo app to
> > detect updates of the library. I've tried ADD_DEPENDENCIES() but to no
> > avail. This is what the tree looks like (partially)
> >
> > fem/
> > -fem/
> > --src/
> > --include/
> > -fem_io/
> > --src/
> > --include
> > -demos/
> > --blendmaterials/
> > ---src/
> >
> > In toplevel fem/CMakeLists.txt
> > PROJECT(fem)
> > ...
> > SET(CMAKE_DEBUG_POSTFIX "d")
> > SET(FEM_LIBS fem)
> > SET(FEM_LIBS_DEBUG femd)
> >
> > In fem/fem/CMakeLists.txt
> > ...
> > ADD_LIBRARY(fem ${FEM_LIBRARY_SOURCES} ${FEM_LIBRARY_HEADERS})
> >
> > In fem/demos/blendmaterials/src/CMakeLists.txt:
> > ...
> > ADD_EXECUTABLE(blendmaterials ${sources} ${headers})
> > ADD_DEPENDENCIES(blendmaterials fem fem_io)
> > TARGET_LINK_LIBRARIES(blendmaterials optimized ${FEM_LIBS} debug
> > ${FEM_LIBS_DEBUG})
>
> Your ADD_DEPENDENCIES is inconsistent for the debug case. I suggest you
> just drop it. Also, try experimenting with a simpler example without
> optimized or debug, e.g.,
>
> TARGET_LINK_LIBRARIES(blendmaterials ${FEM_LIBS})
>
> In my experience, that (without the ADD_DEPENDENCIES) should just work. If
> you still have problems, then I would reduce it down to a really simple
> "hello-world" complete CMake test case that others here can try. It's
> amazing how often I have prepared one of those for the CMake list to
> illustrate a point only to find that the really simple example worked, and
> the problem in the more complicated code was something else entirely such as
> a mispelled variable or scope problem. BTW, liberal use of MESSAGE is a good
> way to debug such problems which are often tough to spot by eyeballing the
> CMake code.
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
>
--
Nico Galoppo :: http://www.ngaloppo.org
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_dependencies question
On 2008-02-19 11:38-0500 Nico Galoppo wrote:
Hi,
I'm trying to get a 'demo' program inside my project tree to link in
(and depend on) one of the built libraries from the same project tree.
I'm having trouble getting the build process for the demo app to
detect updates of the library. I've tried ADD_DEPENDENCIES() but to no
avail. This is what the tree looks like (partially)
fem/
-fem/
--src/
--include/
-fem_io/
--src/
--include
-demos/
--blendmaterials/
---src/
In toplevel fem/CMakeLists.txt
PROJECT(fem)
...
SET(CMAKE_DEBUG_POSTFIX "d")
SET(FEM_LIBS fem)
SET(FEM_LIBS_DEBUG femd)
In fem/fem/CMakeLists.txt
...
ADD_LIBRARY(fem ${FEM_LIBRARY_SOURCES} ${FEM_LIBRARY_HEADERS})
In fem/demos/blendmaterials/src/CMakeLists.txt:
...
ADD_EXECUTABLE(blendmaterials ${sources} ${headers})
ADD_DEPENDENCIES(blendmaterials fem fem_io)
TARGET_LINK_LIBRARIES(blendmaterials optimized ${FEM_LIBS} debug
${FEM_LIBS_DEBUG})
Your ADD_DEPENDENCIES is inconsistent for the debug case. I suggest you
just drop it. Also, try experimenting with a simpler example without
optimized or debug, e.g.,
TARGET_LINK_LIBRARIES(blendmaterials ${FEM_LIBS})
In my experience, that (without the ADD_DEPENDENCIES) should just work. If
you still have problems, then I would reduce it down to a really simple
"hello-world" complete CMake test case that others here can try. It's
amazing how often I have prepared one of those for the CMake list to
illustrate a point only to find that the really simple example worked, and
the problem in the more complicated code was something else entirely such as
a mispelled variable or scope problem. BTW, liberal use of MESSAGE is a good
way to debug such problems which are often tough to spot by eyeballing the
CMake code.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GLOB segmentation fault
Hi, On Tuesday 19 February 2008, pepone.onrez wrote: > [EMAIL PROTECTED] ~/kk/cmake-glob-bug $ cat CMakeLists.txt > FILE (GLOB TESTS ./test/ *.cpp) > > ls -liha test/ > total 0 > 3635635 drwxr-xr-x 3 pepone pepone 72 2008-02-19 04:56 . > 998787 drwxr-xr-x 4 pepone pepone 160 2008-02-19 04:52 .. > 3635679 drwxr-xr-x 2 pepone pepone 48 2008-02-19 04:56 .svn > > > Problem seems to appear when test contains directories files that`s begin > with '.' I still can't reproduce it, my test project is attached. It works both with cmake 2.4.6 (from slackware) and cmake cvs. Does it crash for you ? Alex globproblem.tar.gz Description: application/tgz ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: XXX_DIR
Hi Alexander, On Tuesday 19 February 2008, Fernando Cacciola wrote: Hi people, According to my experiments in 2.4.7, XXX_DIR seems rather special. Consider a CMakeLists.txt containing just "find_package(XYZ)" Run "cmake ." You'll see the error: CMake Error: XYZ_DIR is not set. It must be set to the directory containing XYZConfig.cmake in order to use XYZ. Usually you shouldn't need to set it. Usually maybe.. in the case of my users, they will have to set it to point to the XXXConfig.cmake of my library in order to use it. What do you want to do Understand the way XXX_DIR works. My post shows just that by experimentation, but I wanted to confirm the results. what doesn't work ? The documentation. It should better explain the details of this "magic" variable (magic in the sense that cmake itself uses it). Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com http://groups.google.com/group/cppba Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] XXX_DIR
On Tuesday 19 February 2008, Fernando Cacciola wrote: > Hi people, > > According to my experiments in 2.4.7, XXX_DIR seems rather special. > > Consider a CMakeLists.txt containing just "find_package(XYZ)" > > Run "cmake ." > > You'll see the error: > > CMake Error: XYZ_DIR is not set. It must be set to the directory > containing XYZConfig.cmake in order to use XYZ. Usually you shouldn't need to set it. What do you want to do/what doesn't work ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] add_dependencies question
Hi,
I'm trying to get a 'demo' program inside my project tree to link in
(and depend on) one of the built libraries from the same project tree.
I'm having trouble getting the build process for the demo app to
detect updates of the library. I've tried ADD_DEPENDENCIES() but to no
avail. This is what the tree looks like (partially)
fem/
-fem/
--src/
--include/
-fem_io/
--src/
--include
-demos/
--blendmaterials/
---src/
In toplevel fem/CMakeLists.txt
PROJECT(fem)
...
SET(CMAKE_DEBUG_POSTFIX "d")
SET(FEM_LIBS fem)
SET(FEM_LIBS_DEBUG femd)
In fem/fem/CMakeLists.txt
...
ADD_LIBRARY(fem ${FEM_LIBRARY_SOURCES} ${FEM_LIBRARY_HEADERS})
In fem/demos/blendmaterials/src/CMakeLists.txt:
...
ADD_EXECUTABLE(blendmaterials ${sources} ${headers})
ADD_DEPENDENCIES(blendmaterials fem fem_io)
TARGET_LINK_LIBRARIES(blendmaterials optimized ${FEM_LIBS} debug
${FEM_LIBS_DEBUG})
--
Nico Galoppo :: http://www.ngaloppo.org
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Changing MD -> MT (+patch for free toolkit)
Mathieu Malaterre wrote:
On Feb 19, 2008 5:43 AM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
Mathieu Malaterre wrote:
Ok this was yet-another-weird-dll thingy, one cannot do:
class GDCM_EXPORT String : std::string { ... }
Please, learn a little bit more about C++.
Oh thank you ! I'll take your advice right away, mister expert. So
could you please let me know why *in my particular case* this is
wrong:
1. I did not add any data member
2. I did not overload the dstor
GDCM_EXPORT tells me you are using this in a library.
The reason this is wrong is this. Say you write a function to get a
exension of a filename as uppercase:
GDCM_EXPORT MyString get_extension( const MyString& b )
{
MyString ext = b.to_upper();
// etc... do some other stuff like find '.' and substr
return ext;
}
Now... this will work. But now func() can only be used with your
particular MyString class. However, if you had done:
namespace str {
// to_upper implementation not shown
GDCM_EXPORT std::string to_upper( const std::string& b );
GDCM_EXPORT std::string get_extension( const std::string& b )
{
std::string ext = to_upper( b );
// etc... do some other stuff like find '.' and substr
return ext;
}
}
With this, the code for both to_upper() and get_extension() can be
safely be reused and works for *all* std::string objects. You don't
force people to use your own string library. This makes your library
more attractive and easier to reuse in other code.
Even, if you did not do 1 or 2, you might have done 3:
3. Yo might have overloaded (replaced) a string function.
class MyString : public std::string
{
public:
// silly example, but same applies to add, operator<<, etc.
size_type size() { return std::string::size() + 1; }
};
int main()
{
MyString* s = new MyString;
std::string* c = static_cast< std::string* >( s ); // correct
std::cerr << c->size() << std::endl; // which size() gets called?
// not yours,
// but the one in std::string
return 0;
}
This example for 3) is very simple and obvious but in big programs this
issue may be more confusing as the distintion of what a pointer really
points to becomes more blurry.
If you have only added non-conflicting functions in MyString to
std::string, what you have is safe but potentially not so beneficial.
You might either do as I showed and place your additional functions in a
namespace and keep using std::string everywhere (which makes your
library nice to use and probably popular) or create your own string
class, without deriving anything (and yes, you do need to create a lot
of code for doing a good string class -- it is C++ after all), or create
a proxy string class thru containment of std::string (which is like
creating your own string class from scratch, but a tad simpler):
class MyString
{
std::string str;
public:
typedef std::string::size_type size_type;
// other typedefs similar to std::string...
public:
MyString() {}
MyString(const MyString& b) : str(b.str) {}
MyString(const std::string& b) : str(b) {}
// auto cast to string - optional (only if lazy, may not be wanted)
operator std::string() const { return str; }
// dispatch size function
inline size_type size() const { return str.size(); }
// my functions - not shown
void to_upper();
// dispatch others, etc...
// also remember to add operator=(const std::string& b)
};
This avoids you having to actually write your (potentially buggy) code
to the string functions, as you just dispatch the operations to the
std::string inside your class. And the operator to std::string() and
copy constructor of std::string allows your class to interact with
std::string functions and elements rather seamlessly. It is still
verbose, but not *THAT* much. And the code is probably safer to use
through pointers and easy to extend without conflicts.
Please do not copy some random comment found on the internet and
instead comment on my particular implementation with the following 1
and 2 restrictions. Thanks.
It is not some "random comment". It is good design advice that sadly
applies to all C++ STL classes.
For more information, refer to a good C++ book. IIRCC, Scott Meyer's
Effective STL and Effective C++, covers this and other problems with all
the pitfalls in a very thorough fashion.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Wee question about CMake developer etiquette
> Of course, this doesn't identifies the project leaders, but at least > gives an idea of who has typed enough lines of code to earn the > right to speak for a project. Actually it identifies who committed enough lines ... which is not quite the same as writing them. For CMake the Utilities directories have a lot of code but we did not write most of it. But I'll agree the general idea holds ;) Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Wee question about CMake developer etiquette
On a side note: One of the (many) nice things about Open Source is that credits can be identified in an objective manner. A pragmatic way of identifying the developers of an open source system is to simply look at CVS logs. There are several tools out there that harvest CVS logs and analyze them. "Ohloh", for example, does a great job: http://www.ohloh.net Here is the 'de facto' list of CMake developers: http://www.ohloh.net/projects/3238/contributors?page=1 Note that there are 41 contributors, with levels that range from 163,475 modified lines, to 1 modified line. You could also judge by years of work, or number of commits, or how well commented their code was. (unfortunately, here we can't see how many times they broke the Dashboard, but that's another story :-)). Of course, this doesn't identifies the project leaders, but at least gives an idea of who has typed enough lines of code to earn the right to speak for a project. --- That being said, the point about mailing-list etiquette is very important, and it is worth discussing. It really determines the dynamics of the community. As pointed out at the beginning of this thread, the attitude should also be adjusted when posting to other-projects mailing lists. In that regards, we have a lot to learn from other communities, in particular from the Wikipedia rules on how to engage conflicts: http://en.wikipedia.org/wiki/Wikipedia:Dispute_resolution Although these are not rules for mailing-list, they have proved effective for managing a community of 5 million contributors to the Wikipedia, most of them being anonymous at some level. Of particular interest are: * http://en.wikipedia.org/wiki/Wikipedia:Don%27t_be_a_fanatic * http://en.wikipedia.org/wiki/Wikipedia:Etiquette * http://en.wikipedia.org/wiki/Wikipedia:No_angry_mastodons * http://en.wikipedia.org/wiki/Wikipedia:Beware_of_the_tigers * http://en.wikipedia.org/wiki/Wikipedia:Do_not_feed_the_trolls * http://en.wikipedia.org/wiki/Wikipedia:Please_do_not_bite_the_newcomers * http://en.wikipedia.org/wiki/Wikipedia:Requests_for_medication As you can see, a bit of humor goes a long way in keeping a healthy community together. Luis --- On 2/11/08, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > On Monday 11 February 2008, KHMan wrote: > ... > > As it is, I have tried to look for a list of key developers, but > > since the project is identified more with the company, I was > > unable to find a list of key developers easily. I looked at the > > website and tarball, but didn't manage to get a clear answer. > > The cmake developers are: > -core developers: Bill, Brad and Ken > > -everybody with a @kitware.com email address > And some more contributors, AFAIK all of them are maintaining cmake based > buildsystems for their respective project, e.g. Alan Irwin, Andreas > Schneider, Eric Wing and myself. > > Brandon is an active user (as you can see on this mailing list), but no > cmake > developer or endorsed by the cmake developers or something like that. > > Alex > ___ > 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
[CMake] XXX_DIR
Hi people, According to my experiments in 2.4.7, XXX_DIR seems rather special. Consider a CMakeLists.txt containing just "find_package(XYZ)" Run "cmake ." You'll see the error: CMake Error: XYZ_DIR is not set. It must be set to the directory containing XYZConfig.cmake in order to use XYZ. Define the enviroment variable to the folder containing the CMakeLists.txt file, for intance: export XYZ_DIR=. Run "cmake ." again. You'll see the same error. You could think that this is because XYZ_DIR is defined as a enviroment variable instead of a cmake variable. Let's see. Add an empty file named "XYZConfig.cmake" in the folder pointed to by XYZ_DIR. Run "cmake. " again Now you'll see that it works! Which means that cmake used the enviroment variable XYZ_DIR. Change XYZ_DIR to point somwehre else. Delete CMakeCache.txt Run "cmake ." again. Now you'll see the same "XYZ_DIR is not set" error as before, which suggests that the enviroment variable is recognized only if it points to XYZConfig.cmake Delete CMakeCache.txt again Run "cmake -DZYZ_DIR=wrong_folder ." You'll see the error: CMake Error: XYZ_DIR is set to "wrong_folder", which is not a directory containing XYZConfig.cmake Which shows that if XYZ_DIR is passed as a cmake is it consistently used (unlike the case of an enviroment variable which seems to be used only if it points to the right folder) Furthermore, if you look at the cache at each step above, you'll see that when XYZ_DIR is passed as a cmake variable is not stored in the cache, while when it is passed as an enviroment variable it is (either with a XYZ_DIR-NOITFOUND value or the correct folder value) Can you clarify the details of this variable? Is it true that it can be a enviroment variable but it must point to the right folder? Is it true that if it is a an enviroment variable it is stored in the cache, but not if set in the command line? Can it be stored in the cache if passed in the command line? TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com http://groups.google.com/group/cppba ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: FindXXX, XXXConfig and UseXXX
Brad King wrote: If FindXXX.cmake is found in the paths specified by CMAKE_MODULE_PATH, it is loaded by find_package(XXX). There should not be a FindXXX.cmake at all. OK. So is either FindXXX or XXXConfig, for package configured without and with cmake respectively. If not, but the user sets XXX_DIR to some binary folder for some installation of XXX, the above code works still by loading XXXConfig.cmake directly (witout going through FindXXX..cmake) Is all that correct? Yes. Is so, how should FindXXX and UseXXX distributed? UseXXX.cmake should come with the project next to XXXConfig.cmake. OK. I suppose it could also go the the source tree provided each XXXConfig.cmake point to it via XXX_USE_FILE The whole idea of creating a package with XXXConfig.cmake is to not have to have a FindXXX.cmake module at all. OK The find_package command is supposed to find XXXConfig.cmake automatically, but it is not very good at finding the files as of CMake 2.4 so the user has to set XXX_DIR alot. CMake 2.6 will have a much better find_package: http://www.cmake.org/Wiki/CMake_2.6_Notes#Packages Just read it. You should install XXXConfig.cmake and UseXXX.cmake in the XXX install tree under one of the locations mentioned in the find_package command documentation (as of CMake 2.6). For example, a project on UNIX might install /lib/xxx-1.2/XXXConfig.cmake Hmmm. Shouldn't that be decided by the package user? Right now I generate XXConfig right there in XXX_BINARY_DIR, whatever that is, and use an INSTALL command to copy that to whatever the user chooses as the installation folder (which could be /lib/xxx-1.2, but could be something else). For this package it is importat that a user (such as XXX's testsuite) can use XXX without "installing" it via the install target, that's why I put the config file in the binary folder right away. Someone using CMake 2.4 will have to set XXX_DIR to that directory by hand, but anyone using CMake 2.6 will have the file found automatically. Except on Windows... or are there special search paths for Windows as well? (please look at my upcoming post about XXX_DIR) Versioning is also supported in the CMake 2.6 find_package. See the nots above. I just read it, cool. Thanks -- Fernando Cacciola SciSoft http://fcacciola.50webs.com http://groups.google.com/group/cppba ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: FindXXX, XXXConfig and UseXXX
Brandon Van Every wrote:
On Feb 18, 2008 3:34 PM, Fernando Cacciola
<[EMAIL PROTECTED]> wrote:
XXXConfig.cmake should ...
FindXXX.cmake shoud ...
UseXXX.cmake should set include directories, libraries, compiler and
linker
flags, etc, based on the settings defined in a XXXConfig.cmake that must
has
been processed already.
I've yet to use any of the current UseXXX modules. I looked at the
source for one of them. All they're doing aside from the usual
FindXXX stuff is defining some macros, which you can choose to call or
not call. I don't see a point in breaking all this functionality up
into 3 different include files. 1 is fine; you choose to call
whatever macros you want to call.
Ha, but the UseXXX I was thinking about does the:
include_directories( ${XXX_INCLUDE_DIRS} ${XXX_THIRD_PARTY_INCLUDE_DIRS} )
add_definitions( ${XXX_DEFINITIONS} ${XXX_THIRD_PARTY_DEFINITIONS} )
etc...
XXX users would load XXX in their own programs via:
find_package(XXX)
if ( XXX_FOUND )
include( ${XXX_USE_FILE} )
endif()
What's wrong with:
include(findXXX)
That a users needs to point to findXXX (and there could be various versions
of XXX installed on the system)
Best
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ignore library flags now works in 2.4.8!
I don't see how that SET does anything other than set a variable. It must be how your project uses that variable. VS_MULTITHREADED_DEBUG_IGNORE_LIBRARY_FLAGS is not a variable that CMake looks at... 2.4.8 did fix the problem with multiple /NODEFAULTLIB lines not working. Seems like my last reply is a bit off-topic then ;-) Sorry for this. --Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ignore library flags now works in 2.4.8!
SET(VS_MULTITHREADED_DEBUG_IGNORE_LIBRARY_FLAGS
"/NODEFAULTLIB:nafxcwd.lib
/NODEFAULTLIB:libcmtd.lib"
)
Hello,
Why this kind of variable to implement the ignore flag ?
In order to handle flags with this template : /flags:"parameters" for
Visual Studio projects generation, I propose the following strategy:
-in the cmVS7FlagTable flag table, define a new string value PARAMETERS:
{"IgnoreDefaultLibraryNames",
"NODEFAULTLIB", "default libraries to ignore", "PARAMETERS"},
-in the method FillFlagMapFromCommandFlags handle this value:
if(0 == strcmp(value.c_str(),
"PARAMETERS"))
{
// flags with parameters
int firstPos = flags.find("\"", iBestPos) + 1;
int lastPos = flags.find("\"", firstPos);
std::string parameters = flags.substr(firstPos,
lastPos-firstPos);
value = parameters;
std::string stringToReplace = ":\"" + parameters + "\"";
cmSystemTools::ReplaceString(flags,
stringToReplace.c_str(), "");
}
flagMap[curCommand] = value;
Now it is possible to use any flags with the template
/flags:"parameters" like any other simple flag.
There are already a bunch of specific variables in CMake, generator
specific variables should be avoided and replaced by a conditionnal
block to set the correct flag for the current generator.
I attached my flag table and method to handle it. There is also another
feature: if there are
several occurences of the same flag in the string, then only the
left-most flag is processed, the other are discarded (it provides
support for flag overwriting without knowing which flag is already,
useful in sub-directories).
--Sylvain
// This is a table mapping XML tag IDE names to command line options
struct cmVS7FlagTable
{
const char* IDEName; // name used in the IDE xml file
const char* commandFlag; // command line flag
const char* comment; // comment
const char* value; // string value
};
cmVS7FlagTable cmLocalVisualStudio7GeneratorMPCompilerFlagTable[] =
{
// option flags (some flags map to the same option)
// C/C++
--
// General
{"DebugInformationFormat","Z7", "debug
format", "1"},
{"DebugInformationFormat","Zd", "debug
format", "2"},
{"DebugInformationFormat","Zi", "debug
format", "3"},
{"DebugInformationFormat","ZI", "debug
format", "4"},
{"SuppressStartupBanner", "nologo",
"SuppressStartupBanner", "TRUE"},
{"SuppressStartupBanner", "logo", "Do not
SuppressStartupBanner", "FALSE"},
{"WarningLevel", "W1", "Warning
level", "1"},
{"WarningLevel", "W2", "Warning
level", "2"},
{"WarningLevel", "W3", "Warning
level", "3"},
{"WarningLevel", "W4", "Warning
level", "4"},
{"Detect64BitPortabilityProblems","noWp64", "Do not
Detect 64-bit Portability Issues","FALSE"},
{"Detect64BitPortabilityProblems","Wp64", "Detect
64-bit Portability Issues", "TRUE"},
{"WarnAsError", "noWX", "Do not
Treat warnings as errors","FALSE"},
{"WarnAsError", "WX", "Treat
warnings as errors", "TRUE"},
// Optimization
{"Optimization", "Od", "Non
Debug", "0"},
{"Optimization", "O1", "Min
Size", "1"},
{"Optimization", "O2", "Max
Speed", "2"},
{"Optimization", "Ox", "Max
Optimization", "3"},
{"GlobalOptimizations", "noOg", "Do not
Global Optimizations","FALSE"},
{"GlobalOptimizations", "Og", "Global
Optimizations", "TRUE"},
{"InlineFunctionExpansion", "Ob0", "no
inlines", "0"},
{"InlineFunctionExpansion", "Ob1", "when
inl
[CMake] ctest - how to set environment
Hi,
I just started using CMake (2.4) and I'm very happy about the easy build
setup. Encouraged by this quick success I tried to enable testing. But I
cannot get working the tests correctly.
My test executable needs an environment variable, which is not set in my
standard session. As I understood the doku I can set environment variables
for the test session by "set( CTEST_ENVIRONMENT...", but this doesn't work as
expected. Here is my test setup:
My test executable is the following shell script:
echo ICU_DATA: ${ICU_DATA}
The test part of my CMakeLists.txt looks like this (enable_testing() called in
top dir):
set( CTEST_ENVIRONMENT "ICU_DATA=bla" )
add_test( EnvTest ${output_directory}/test )
Unfortunately the result in LastTest.log looks like this:
"ICU_DATA:"
where I expect "ICU_DATA: bla"
Can anybody put some light on the environment variable handling for testing
sessions?
Thanks
Jörg
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Changing MD -> MT (+patch for free toolkit)
On Feb 19, 2008 5:43 AM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
> Mathieu Malaterre wrote:
> > Ok this was yet-another-weird-dll thingy, one cannot do:
> >
> > class GDCM_EXPORT String : std::string { ... }
> >
>
> Please, learn a little bit more about C++.
Oh thank you ! I'll take your advice right away, mister expert. So
could you please let me know why *in my particular case* this is
wrong:
1. I did not add any data member
2. I did not overload the dstor
Please do not copy some random comment found on the internet and
instead comment on my particular implementation with the following 1
and 2 restrictions. Thanks.
> You should never inherit
> from std::string (or any std::* container) as their functions or
> destructor are not virtual. That can (and will) spell disaster for
> anyone else trying to use your library/functions or even for yourself if
> you go through pointers or references.
I know exactly what I was doing, and I still need a 'string-like'
class with an overloaded operator:
inline std::istream& operator>>(std::istream &is, MyString &ms);
Having std::string as member rather than inherited would means *tons*
of duplicated code, and in my particular case inheriting was perfectly
safe.
Je ne vous salut pas monsieur,
--
Mathieu
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
