Re: [CMake] Alternative IDL compiler, and adding non-present sources
2009/1/27 Jose Luis Blanco : > Hi all! > > Issue 1: > > Porting an old project to CMake I realized there's no way to modify the > predefined behavior when one adds an IDL file to a Visual Studio > project, which is associating it to "midl". > > In our project we'd rather need to execute a different IDL compiler > (TAO_IDL), but declaring an "add_custom_command" i.e. in PREBUILD has no > effect since the "midl" association is hard-coded in the generator. There is a pending bug open for this issue: http://public.kitware.com/Bug/view.php?id=7845 > I am thinking on writing a patch for this, but prefer to have opinions > about the preferred way to do it to be consistent with the rest of CMake > commands and variables. > > > Issue 2: > > Also related to the compilation of IDL files: If .cpp/.h files, which > does not exist yet but will be built by the IDL compiler, are added to > the project, CMake correctly complains about non-existing sources... Is > there any way to force CMake to add them and "trust us" that those > sources will exist someday? Yes there is you can flag the files as "GENERATED" with: set_source_files_properties(file1 file2 PROPERTIES GENERATED TRUE) -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with FindwxWidgets.cmake
So you have two choices to get it to work with CMake 2.6.2: modify
FindwxWidgets.cmake to look in the mswu directory, or set
wxWidgets_LIB_DIR yourself
before doing the wx find... Either one should get you one step further
along.
If it is also happening with CVS HEAD of CMake, then I would open an issue
in the bug tracker against the FindwxWidgets.cmake module that says "cannot
find the UNICODE wxWidgets_LIB_DIR because 'mswu' is not searched..."
HTH,
David
On Mon, Jan 26, 2009 at 7:49 PM, Robert Dailey wrote:
> Hi,
>
> I'm currently using CMake 2.6.2 and the FindwxWidgets.cmake module that
> comes pre-packaged with the installation doesn't seem to properly work on
> windows. I set CMAKE_PREFIX_PATH so that it would be able to find the
> wxWidgets in a custom location. It does find wxWidgets_ROOT_DIR, but does
> not find wxWidgets_LIB_DIR. We are using a unicode build of wxWidgets on
> Windows, and our lib directory looks like:
>
> ${wxWidgets_ROOT_DIR}/lib/mswu/wx/setup.h
>
> However, look at this snippet of code from FindwxWidgets.cmake:
>
> FIND_PATH(wxWidgets_LIB_DIR
> NAMES msw/build.cfg mswd/build.cfg
> PATHS
> ${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_dll # prefer shared
> ${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_lib
> DOC "Path to wxWidgets libraries?"
> NO_DEFAULT_PATH
> )
>
> Notice it is only checking in "msw" and not "mswu". Also, I do not have a
> build.cfg file (I only keep relevant files inside my wxWidgets directory).
> This file is enormous and complex, so I'm not even sure if this code is even
> being used or if it matters.
>
> The output I'm getting from the GUI CMake tool is:
>
> CMake Error at C:/Program Files/CMake
> 2.6/share/cmake-2.6/Modules/FindPackageHandleStandardArgs.cmake:57
> (MESSAGE):
>
> Could NOT find wxWidgets (missing: wxWidgets_FOUND)
>
> Call Stack (most recent call first):
>
> C:/Program Files/CMake 2.6/share/cmake-2.6/Modules/FindwxWidgets.cmake:765
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>
> tools/tile_editor/CMakeLists.txt:1 (find_package)
>
> Can anyone help me figure out what is going on? This thing *should* be
> simple to use! Thanks.
>
> ___
> 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] Alternative IDL compiler, and adding non-present sources
Eric Noulard wrote: 2009/1/27 Jose Luis Blanco : Hi all! Issue 1: Porting an old project to CMake I realized there's no way to modify the predefined behavior when one adds an IDL file to a Visual Studio project, which is associating it to "midl". In our project we'd rather need to execute a different IDL compiler (TAO_IDL), but declaring an "add_custom_command" i.e. in PREBUILD has no effect since the "midl" association is hard-coded in the generator. There is a pending bug open for this issue: http://public.kitware.com/Bug/view.php?id=7845 I am thinking on writing a patch for this, but prefer to have opinions about the preferred way to do it to be consistent with the rest of CMake commands and variables. = Just fixed it, will make sure the fix goes into 2.6.3 cvs commit -m "BUG: fix for 7845, idl files compile even with headerfile only on" cmLocalVisualStudio7Generator.cxx Committer: Bill Hoffman /cvsroot/CMake/CMake/Source/cmLocalVisualStudio7Generator.cxx,v <-- cmLocalVisualStudio7Generator.cxx new revision: 1.236; previous revision: 1.235 -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Function variable name question
I have the following code in a script:
function(set_var var)
message("var = ${var}")
message("${var} = ${${var}}")
set(${var} "new_val")
message("${var} = ${${var}}\n")
endfunction()
set(myvar 10)
set_var(myvar)
# Empty variable
set_var(myvar2)
set_var(var)
# Set variable
set(var 11)
set_var(var)
When I run it I get the following output:
var = myvar
myvar = 10
myvar = new_val
var = myvar2
myvar2 =
myvar2 = new_val
var = var
var = var
new_val =
var = var
var = var
new_val =
I get expected output when the name of the variable I pass in isn't the same
as the one used in the function parameter list.
Is this the desired behavior of the language? I would argue that it isn't,
because you get different behavior based on the name of the variable passed
in.
I'm using CMake 2.6.3R8 on WinXP 64.
Thanks,
James
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with FindwxWidgets.cmake
Thanks for your response guys.
I ended up changing the NAMES argument to the respective find_path() call to
include mswu and mswud. This will work for the time being.
On Tue, Jan 27, 2009 at 8:41 AM, David Cole wrote:
> So you have two choices to get it to work with CMake 2.6.2: modify
> FindwxWidgets.cmake to look in the mswu directory, or set
> wxWidgets_LIB_DIR yourself before doing the wx find... Either one should
> get you one step further along.
> If it is also happening with CVS HEAD of CMake, then I would open an issue
> in the bug tracker against the FindwxWidgets.cmake module that says "cannot
> find the UNICODE wxWidgets_LIB_DIR because 'mswu' is not searched..."
>
>
> HTH,
> David
>
>
> On Mon, Jan 26, 2009 at 7:49 PM, Robert Dailey wrote:
>
>> Hi,
>>
>> I'm currently using CMake 2.6.2 and the FindwxWidgets.cmake module that
>> comes pre-packaged with the installation doesn't seem to properly work on
>> windows. I set CMAKE_PREFIX_PATH so that it would be able to find the
>> wxWidgets in a custom location. It does find wxWidgets_ROOT_DIR, but does
>> not find wxWidgets_LIB_DIR. We are using a unicode build of wxWidgets on
>> Windows, and our lib directory looks like:
>>
>> ${wxWidgets_ROOT_DIR}/lib/mswu/wx/setup.h
>>
>> However, look at this snippet of code from FindwxWidgets.cmake:
>>
>> FIND_PATH(wxWidgets_LIB_DIR
>> NAMES msw/build.cfg mswd/build.cfg
>> PATHS
>> ${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_dll # prefer shared
>> ${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_lib
>> DOC "Path to wxWidgets libraries?"
>> NO_DEFAULT_PATH
>> )
>>
>> Notice it is only checking in "msw" and not "mswu". Also, I do not have a
>> build.cfg file (I only keep relevant files inside my wxWidgets directory).
>> This file is enormous and complex, so I'm not even sure if this code is even
>> being used or if it matters.
>>
>> The output I'm getting from the GUI CMake tool is:
>>
>> CMake Error at C:/Program Files/CMake
>> 2.6/share/cmake-2.6/Modules/FindPackageHandleStandardArgs.cmake:57
>> (MESSAGE):
>>
>> Could NOT find wxWidgets (missing: wxWidgets_FOUND)
>>
>> Call Stack (most recent call first):
>>
>> C:/Program Files/CMake 2.6/share/cmake-2.6/Modules/FindwxWidgets.cmake:765
>> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>>
>> tools/tile_editor/CMakeLists.txt:1 (find_package)
>>
>> Can anyone help me figure out what is going on? This thing *should* be
>> simple to use! Thanks.
>>
>> ___
>> 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] Function variable name question
On Tue, Jan 27, 2009 at 10:46 AM, Matthew Woehlke <
mw_tr...@users.sourceforge.net> wrote:
> James Bigler wrote:
>
>> I have the following code in a script:
>>
>> function(set_var var)
>> message("var = ${var}")
>> message("${var} = ${${var}}")
>> set(${var} "new_val")
>> message("${var} = ${${var}}\n")
>> endfunction()
>>
>> set(myvar 10)
>> set_var(myvar)
>>
>> # Empty variable
>> set_var(myvar2)
>>
>> set_var(var)
>>
>> # Set variable
>> set(var 11)
>> set_var(var)
>>
>> When I run it I get the following output:
>>
>> var = myvar
>> myvar = 10
>> myvar = new_val
>>
>> var = myvar2
>> myvar2 =
>> myvar2 = new_val
>>
>> var = var
>> var = var
>> new_val =
>>
>> var = var
>> var = var
>> new_val =
>>
>> I get expected output when the name of the variable I pass in isn't the
>> same
>> as the one used in the function parameter list.
>>
>> Is this the desired behavior of the language? I would argue that it
>> isn't,
>> because you get different behavior based on the name of the variable
>> passed
>> in.
>>
>
> Um... and how would you claim it is supposed to work? You've got a classic
> case of variable shadowing here. If you think about it, CMake is doing
> exactly what you told it to do.
>
> IOW, don't do that ;-).
>
GI see that now.
${var} evaluates to var and there's no way to know if that's the function's
var or the global scope's var.
I know you could probably mangle the parameter names to decrease the
probability of collisions, but is there any assured method to avoid
collisions?
James
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Function variable name question
James Bigler wrote:
On Tue, Jan 27, 2009 at 10:46 AM, Matthew Woehlke <
mw_tr...@users.sourceforge.net> wrote:
James Bigler wrote:
I have the following code in a script:
function(set_var var)
message("var = ${var}")
message("${var} = ${${var}}")
set(${var} "new_val")
message("${var} = ${${var}}\n")
endfunction()
set(myvar 10)
set_var(myvar)
# Empty variable
set_var(myvar2)
set_var(var)
# Set variable
set(var 11)
set_var(var)
When I run it I get the following output:
var = myvar
myvar = 10
myvar = new_val
var = myvar2
myvar2 =
myvar2 = new_val
var = var
var = var
new_val =
var = var
var = var
new_val =
I get expected output when the name of the variable I pass in isn't the
same
as the one used in the function parameter list.
Is this the desired behavior of the language? I would argue that it
isn't,
because you get different behavior based on the name of the variable
passed
in.
Um... and how would you claim it is supposed to work? You've got a classic
case of variable shadowing here. If you think about it, CMake is doing
exactly what you told it to do.
GI see that now.
${var} evaluates to var and there's no way to know if that's the function's
var or the global scope's var.
Right :-).
I know you could probably mangle the parameter names to decrease the
probability of collisions, but is there any assured method to avoid
collisions?
I doubt there is a technical way to do it (it would be complicated, with
questionable value compared to the cost). Enforcing a good naming scheme
is probably your best bet; you could, for example, prefix parameter
names with the name of the function.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Anyone who is capable of getting themselves made President should on no
account be allowed to do the job. -- Douglas Adams
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Function variable name question
James Bigler wrote:
I have the following code in a script:
function(set_var var)
message("var = ${var}")
message("${var} = ${${var}}")
set(${var} "new_val")
message("${var} = ${${var}}\n")
endfunction()
set(myvar 10)
set_var(myvar)
# Empty variable
set_var(myvar2)
set_var(var)
# Set variable
set(var 11)
set_var(var)
When I run it I get the following output:
var = myvar
myvar = 10
myvar = new_val
var = myvar2
myvar2 =
myvar2 = new_val
var = var
var = var
new_val =
var = var
var = var
new_val =
I get expected output when the name of the variable I pass in isn't the same
as the one used in the function parameter list.
Is this the desired behavior of the language? I would argue that it isn't,
because you get different behavior based on the name of the variable passed
in.
Um... and how would you claim it is supposed to work? You've got a
classic case of variable shadowing here. If you think about it, CMake is
doing exactly what you told it to do.
IOW, don't do that ;-).
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Anyone who is capable of getting themselves made President should on no
account be allowed to do the job. -- Douglas Adams
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with FindwxWidgets.cmake
On Mon, Jan 26, 2009 at 8:49 PM, Robert Dailey wrote:
> Hi,
>
> I'm currently using CMake 2.6.2 and the FindwxWidgets.cmake module that
> comes pre-packaged with the installation doesn't seem to properly work on
> windows. I set CMAKE_PREFIX_PATH so that it would be able to find the
> wxWidgets in a custom location. It does find wxWidgets_ROOT_DIR, but does
> not find wxWidgets_LIB_DIR. We are using a unicode build of wxWidgets on
> Windows, and our lib directory looks like:
>
> ${wxWidgets_ROOT_DIR}/lib/mswu/wx/setup.h
>
> However, look at this snippet of code from FindwxWidgets.cmake:
>
> FIND_PATH(wxWidgets_LIB_DIR
> NAMES msw/build.cfg mswd/build.cfg
> PATHS
> ${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_dll # prefer shared
> ${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_lib
> DOC "Path to wxWidgets libraries?"
> NO_DEFAULT_PATH
> )
>
> Notice it is only checking in "msw" and not "mswu". Also, I do not have a
> build.cfg file (I only keep relevant files inside my wxWidgets directory).
> This file is enormous and complex, so I'm not even sure if this code is even
> being used or if it matters.
Hello Robert,
This was a regression error while trying handle MinGW. You should only
need to replace your FindwxWidgets.cmake with the latest version
available from the following link:
http://www.cmake.org/cgi-bin/viewcvs.cgi/Modules/FindwxWidgets.cmake?root=CMake&view=markup
Of course, setting the wxWidgets_LIB_DIR manually in the gui or
command line should also work.
--Miguel
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] printing a message post make install
Hi all, I need to notify users right after they have done 'make install' and my idea was to put a: install(CODE "MESSAGE(\"some message\")") ...last in my top-level CMakeLists.txt. This won't work as the message will get printed before all the "Installing..." and "Up-to-date..." messages. Is there any way to get a message printed *last* in the make install step? The other solution I thought about would be to create a custom target that depends on the last built and installed target but this is uglier IMO and is harder to do since the last target will be different from user to user depending on what parts that specific user wants to build. cheers Mattias ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Adding a custom target that depends on top-level `all' target.
Greetings, If question is already answered somewhere, just point us to it. I couldn't find an answer in the CMake Wiki or FAQ. How do I create a custom target in a subdirectory that is dependent on the top-level target `all'? The simple command `add_dependencies (foo all)' doesn't work. Thanks, Eric. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding a custom target that depends on top-level `all' target.
Eric Lemings wrote: If question is already answered somewhere, just point us to it. I couldn't find an answer in the CMake Wiki or FAQ. Did you try Reading The Fine Man[page]? ;-) (Or, 'cmake --help-command add_custom_target'.) How do I create a custom target in a subdirectory that is dependent on the top-level target `all'? The simple command `add_dependencies (foo all)' doesn't work. 'add_custom_target(my_target ALL ...)'? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Anyone who is capable of getting themselves made President should on no account be allowed to do the job. -- Douglas Adams ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ActiveQt
On Wed, Jan 21, 2009 at 10:28 PM, Clinton Stimpson wrote: Here come patches for FindQt4.cmake and UseQt4.cmake against CVS. While other Qt modules only have one library, ActiveQt are two libraries (AxContainer and AxServer). As I wanted to mimic the existing style, there are three library variables: QT_ACTIVEQT_AXCONTAINER_LIBRARY, QT_ACTIVEQT_AXSERVER_LIBRARY and QT_ACTIVEQT_LIBRARY (which is the concatenation of the two former libraries). Please take a look and tell me what you think. I will add a QT_DUMP_CPP macro which wraps "dumpcpp" but that won't be until at least this weekend. > > It doesn't support ActiveQt, but patches are welcome. > > Clint > > Pau Garcia i Quiles wrote: >> >> Hello, >> >> Does FindQt4.cmake support ActiveQt (only available in Qt4 for >> Windows, commercial edition) ? It looks like it does not because I >> don't see a QT_USE_ACTIVEQT variable, and it does not look for >> QAxContainer or QAxServer >> >> > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) UseQt4.cmake.diff Description: Binary data FindQt4.cmake.diff Description: Binary data ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to configure build output directory
I want to use CMake to configure a project that will build several applications. I would like things such that each built program ends up in a directory path like: .../BuildDirectory/Debug/ApplicationName/AppliationName(.exe) What is needed to cause CMake to configure this kind of build output? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Regression between 2.4.8 and 2.6.2 for the macada version of the gcc compiler
One of the PLplot developers has been using the macada version of the gcc compiler on Mac OS X for a long time because that version gives him an integrated Ada compiler as well. That compiler worked well for cmake-2.4, but he has recently run into build problems for cmake-2.6. The issue can be illustrated by a simple "hello-world" shared library build test project with SOVERSION and VERSION specified for the library. You can svn checkout that simple test from https://plplot.svn.sourceforge.net/svnroot/plplot/branches/test_cmake/test_c_library_build His platform is OS X version 10.4.11 on a ppc processor. I present three different VERBOSE=1 "make" output results that he obtained with the above simple test project. I) CMake-2.6.2 using the standard Apple compiler with the following gcc -v results: Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure -- disable-checking -enable-werror --prefix=/usr --mandir=/share/man -- enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg] [^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with- slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple- darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5363) For this compiler all is well for CMake-2.6.2 (see the attached make.out_gcc_std_2.6.2). However, note he cannot use that standard compiler for his ordinary PLplot development that strongly focusses on Ada. II) CMake-2.4.8 using the macada gcc compiler with the following gcc -v results: Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /Users/drew/Developer/Compiler/gcc-head/configure --disable-checking --disable-nls --enable-static --prefix=/usr/local/ada-4.3 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --enable-languages=c,ada,c++,fortran,objc,obj-c++ Thread model: posix gcc version 4.3.0 20070904 (experimental) [trunk revision 128067] (GCC) For this compiler all is well for CMake-2.4.8 (see the attached make.out_gcc_macada_2.4.8). The macada compiler package also provides an integrated Ada compiler so this is the one he has been using for his PLplot development. Note, the linking for 2.4.8 is done without use of the -current_version flag. III) CMake-2.6.2 using the macada gcc compiler with the above gcc -v results. For this compiler all is not well for CMake-2.6.2 (see the attached make.out_gcc_macada_2.6.2). The -current_version flag used by CMake-2.6.2 is not recognized by this compiler (or probably more likely the linker associated with this compiler). That flag is specified by cmake-2.6/Modules/Platform/Darwin.cmake. Can somebody recommend a fix to that file so that CMake-2.6.2 works just as well as CMake-2.4.8 for the macada version of the gcc compiler? I have no idea whether gcc should always be expected to recognize the -current_version flag. That is, I cannot conclude one way or the other whether this problem is due to a macada compiler deficiency or incorrect CMake-2.6.2 assumption about gcc. However, this developer is currently completely stuck because PLplot now uses 2.6.0 as the minimum version. (I got tired of maintaining build-system logic for the two separate versions so I recently ripped out the 2.4.8-specific stuff. It was only at that point, that it turned out this developer had failed to do the requested testing of 2.6.0 before the final changeover, but that is the way it often goes when testing is requested.) I hope somebody can come up with an idea to at least work around the issue for CMake-2.6.x because I would hate to be forced to put the 2.4.8 cruft back into the PLplot build system. 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 __-- The C compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/temp Running make. "/Applications/CMake 2.6-2.app/Contents/bin/cmake" -H/Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/test_c_library_build -B/Users/me/Documents/Programs/Ada/Code/Bindings/PLplot/plplot_svn/temp --check-build-system CMakeFiles/Makefile.cmake 0 "/Applications/CMake 2.6-2.app/Conte
