[CMake] Errors in OSX platform and ubuntu of a Qt app
Hi, I'm not an expert of cmake so please, forgive me is the question is stupid. I'm migrating an application from qmake to cmake. The apps _only_ needs qt4 and libpq (postgresql). I can compile the application in a Debian Etch without any problem with cmake 2.4.5 and 2.4.7 (an own backport) and qt 4.2 . I have a parther that cannot compile the application in ubuntu given linked errors (with cmake 4.6 and qt 4.2) and also another cannot compile it in OSX, because another undefined symbols. My question is, have I to take care something special for OSX platforms or if I can build it in a platform, the problems in anothers platforms are not cmake issues? If someone want to check it, the project is Open Source and you can test it doing this: svn checkout http://svn.berlios.de/svnroot/repos/bulmages/trunk/bulmages trunk-bulmages cd trunk-bulmages mkdir build cd build cmake ../ make you only needs the qt> 4.2 development files and the postgresql (libpq) dev files. Regards, Leo ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] OpenSceneGraph Find Modules
On Dec 10, 2007 9:40 AM, E. Wing wrote: > That's all I can remember on Mac issues for the moment. But on a > general CMake issue, I just submitted a whole bunch of Find*.cmake > modules for inclusion. > http://www.cmake.org/Bug/view.php?id=6139 > > Some of them are updates to existing modules that I have contributed. > Others are brand new modules that I've been promising but needed to do > significant clean up before submitting. (So that's where my weekend > went.) > > FindFreeType.cmake > FindGDAL.cmake > FindGIFLIB.cmake > FindLua50.cmake > FindLua51.cmake > FindOpenAL.cmake > FindOpenSceneGraph.cmake > FindOpenThreads.cmake > FindPhysFS.cmake > FindProducer.cmake > FindQuickTime.cmake > FindSDL.cmake > FindSDL_image.cmake > FindSDL_mixer.cmake > FindSDL_net.cmake > FindSDL_sound.cmake > FindSDL_ttf.cmake > Findosg.cmake > FindosgDB.cmake > FindosgFX.cmake > FindosgGA.cmake > FindosgIntrospection.cmake > FindosgManipulator.cmake > FindosgParticle.cmake > FindosgProducer.cmake > FindosgShadow.cmake > FindosgSim.cmake > FindosgTerrain.cmake > FindosgText.cmake > FindosgUtil.cmake > FindosgViewer.cmake Hello Eric, I think these modules are a great addition to CMake. Thanks! However, I took a look at them and I'm concerned with uniformity with other modules. Now, I may be coming at it from a totally ignorant point of view, since I don't know any history behind them (e.g., I'll definitely not be aware of things that can't be changed do to backwards compatibility, etc.), so please take these suggestions with a grain of salt. I think that for packages that are external components of OSG, such as OpenGL, Producer, Quicktime, Lua, giflib, etc., there should be a separate module. However, all OSG components should be found in the same module (e.g., FindOpenSceneGraph.cmake). By having them separate it increases the maintainence burden, and people are more likely to get confused. If there are optional components, which you might or might not want to link in, you can use the COMPONENTS/REQUIRED interface of FIND_PACKAGE. For instance, the user would do something like: FIND_PACKAGE(OpenSceneGraph COMPONENTS DB FX GA Introspection) to use those particular modules only. That's the way I do it in the FindwxWidgets module. I suppose, you could also use the FindQt4 approach of having to set variables before calling the module (e.g., OSG_USE_DB, OSG_USE_FX, OSG_USE_GA, OSG_USE_INTROSPECTION). Furthermore, if you already build OSG using CMake (great choice btw ;) ), then you might prefer to request the CMake cache variable OpenSceneGraph_DIR to be set to the path of a file OpenSceneGraphConfig.cmake (take a look at: cmake --help-command find_package), where all the configuration options that where used for that particular OSG build can be found and so it is much user friendly to use the module. The user would do: FIND_PACKAGE(OpenSceneGraph) and by changing the location of the OpenSceneGraph_DIR variable all the correct (as defined by the OSG developers) options are set for that build. I'm interested in standardizing the cmake find modules and I would like to start using OpenSceneGraph some time soon for a course, so I'm willing to volunteer some testing and development time into these suggestions if you think they are reasonable and appropriate. Of course, making the changes before releasing them with CMake helps avoid backwards compatibility issues. Hope this helps, --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Controling OutputDirectory in the vcprojs
Hi, I'm porting (or trying to) a custom build system to CMake. Following Boost we generate .libs whose names reflect configurarion properties. To keep it simple, say we generate "foo_release.lib" and "foo_debug-lib". I was able to get those names right by setting the -OUTPUT-NAME target properties, but I still have a problem: I don't want them in "Release" and "Debug" folders (there is no need for that since the configuration is in the name). Looking at "cmLocalVisualStudio7Generator.cxx" it seems I'm plain out of luck since "OutputDirectory" is forcibly defined as the configuration name, so 1) Can the VisualStudio generator be fixed to define that as LIBRARY_OUTPUT_DIRECTORY if defined? 2) What can I do now? Can I plug in a post build event to copy the generated .lib to the right folder? Or do I need to handle it as an install rule? (and force my users to do "make install" in the end even for in-source builds) TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Errors in OSX platform and ubuntu of a Qt app
I don't have Postgres SQL so I can not try your build on OS X. Could you post the link errors from the OS X machine? Maybe someone can be of more help. Generally I have few problems compiling my code on 64 bit linux and OS X. -- Mike Jackson Senior Research Engineer Innovative Management & Technology Services On Dec 12, 2007, at 5:17 AM, Leopold Palomo-Avellaneda wrote: Hi, I'm not an expert of cmake so please, forgive me is the question is stupid. I'm migrating an application from qmake to cmake. The apps _only_ needs qt4 and libpq (postgresql). I can compile the application in a Debian Etch without any problem with cmake 2.4.5 and 2.4.7 (an own backport) and qt 4.2 . I have a parther that cannot compile the application in ubuntu given linked errors (with cmake 4.6 and qt 4.2) and also another cannot compile it in OSX, because another undefined symbols. My question is, have I to take care something special for OSX platforms or if I can build it in a platform, the problems in anothers platforms are not cmake issues? If someone want to check it, the project is Open Source and you can test it doing this: svn checkout http://svn.berlios.de/svnroot/repos/bulmages/trunk/ bulmages trunk-bulmages cd trunk-bulmages mkdir build cd build cmake ../ make you only needs the qt> 4.2 development files and the postgresql (libpq) dev files. Regards, Leo ___ 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] Logarithms in MATH expressions
Anyone who knows wheter it's possible to calculate logarithms in MATH expressions in CMake? Would like a log2 or alternatively "ln" (natural). -Martin -Original Message- From: [EMAIL PROTECTED] on behalf of Fernando Cacciola Sent: Wed 12/12/2007 2:29 PM To: cmake@cmake.org Subject: [CMake] Controling OutputDirectory in the vcprojs Hi, I'm porting (or trying to) a custom build system to CMake. Following Boost we generate .libs whose names reflect configurarion properties. To keep it simple, say we generate "foo_release.lib" and "foo_debug-lib". I was able to get those names right by setting the -OUTPUT-NAME target properties, but I still have a problem: I don't want them in "Release" and "Debug" folders (there is no need for that since the configuration is in the name). Looking at "cmLocalVisualStudio7Generator.cxx" it seems I'm plain out of luck since "OutputDirectory" is forcibly defined as the configuration name, so 1) Can the VisualStudio generator be fixed to define that as LIBRARY_OUTPUT_DIRECTORY if defined? 2) What can I do now? Can I plug in a post build event to copy the generated .lib to the right folder? Or do I need to handle it as an install rule? (and force my users to do "make install" in the end even for in-source builds) TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ 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] Errors in OSX platform and ubuntu of a Qt app
A Dimecres 12 Desembre 2007 14:06, Mike Jackson va escriure: > I don't have Postgres SQL so I can not try your build on OS X. only need the libpq with the /usr/include/postgresql/* includes files. Please, if you could do it I will thank you a lot. > Could > you post the link errors from the OS X machine? Maybe someone can be > of more help. > Generally I have few problems compiling my code on 64 bit linux and > OS X. Well, the cmake works, but it fails at 34% when link a shared library. At Debian it doesn't fails. The user sent me the output that is below. Regards, Leo ###3 Scanning dependencies of target pluginregistrodeiva [ 34%] Building CXX object bulmacont/plugins/pluginregistroiva/ CMakeFiles/pluginregistrodeiva.dir/moc_ui_cobropagobase.o [ 34%] Building CXX object bulmacont/plugins/pluginregistroiva/ CMakeFiles/pluginregistrodeiva.dir/moc_ui_listregistroivabase.o [ 34%] Building CXX object bulmacont/plugins/pluginregistroiva/ CMakeFiles/pluginregistrodeiva.dir/moc_ui_registroivabase.o Linking CXX shared library libpluginregistrodeiva.dylib Undefined symbols: "aplinteligentesview::aplinteligentesview(Empresa*, QWidget*)", referenced from: linprevcobro::creaPago() in linprevcobro.o "aplinteligentesview::setfechaasiento(QString)", referenced from: linprevcobro::creaPago() in linprevcobro.o "regivaprintview::regivaprintview(Empresa*, QWidget*)", referenced from: ListRegistroIvaView::boton_print() in listregistroivaview.o "BusquedaCuenta::BusquedaCuenta(QWidget*)", referenced from: Ui_CobroPagoBase::setupUi(QWidget*) in cobropagoview.o Ui_RegistroIvaBase::setupUi(QWidget*) in registroivaview.o "aplinteligentesview::inicializa(int)", referenced from: linprevcobro::creaPago() in linprevcobro.o "FichaBc::FichaBc(Empresa*, QWidget*, QFlags)", referenced from: RegistroIva::RegistroIva(Empresa*, QWidget*)in registroiva.o "aplinteligentesview::setvalores(QString, QString)", referenced from: linprevcobro::creaPago() in linprevcobro.o linprevcobro::creaPago() in linprevcobro.o linprevcobro::creaPago() in linprevcobro.o linprevcobro::creaPago() in linprevcobro.o "Asiento1View::muestraasiento(int)", referenced from: ListLinPrevCobroView::contextMenu(int, int, QPoint const&)in listlinprevcobroview.o ListRegistroIvaView::on_mui_tablasoportado_cellDoubleClicked(int, int)in listregistroivaview.o ListRegistroIvaView::on_mui_tablarepercutido_cellDoubleClicked(int, int)in listregistroivaview.o ListRegistroIvaView::on_mui_tablasoportado_trataMenu(QAction*) in listregistroivaview.o ListRegistroIvaView::on_mui_tablarepercutido_trataMenu(QAction*) in listregistroivaview.o "Bulmacont::empresaactual()", referenced from: myRegIVA::elslot() in pluginregistroiva.o myRegIVA::elslot() in pluginregistroiva.o myRegIVA::elslot1() in pluginregistroiva.o myRegIVA::elslot1() in pluginregistroiva.o "Empresa::numdigitosempresa()", referenced from: linprevcobro::setcodigocuenta(QString) in linprevcobro.o linprevcobro::setcodigoctacliente(QString) in linprevcobro.o "FichaBc::qt_metacall(QMetaObject::Call, int, void**)", referenced from: vtable for RegistroIvain registroiva.o RegistroIvaView::qt_metacall(QMetaObject::Call, int, void**)in moc_registroivaview.o "Asiento1::companyact()", referenced from: _Asiento1_guardaAsiento1_post in pluginregistroiva.o "FichaBc::empresaBase()", referenced from: vtable for RegistroIvain registroiva.o RegistroIvaView::RegistroIvaView(Empresa*, QWidget*)in registroivaview.o vtable for RegistroIvaViewin moc_registroivaview.o "SubForm2Bc::SubForm2Bc(QWidget*)", referenced from: Ui_CobroPagoBase::setupUi(QWidget*) in cobropagoview.o Ui_ListRegistroIvaBase::setupUi(QWidget*) in listregistroivaview.o Ui_ListRegistroIvaBase::setupUi(QWidget*) in listregistroivaview.o Ui_ListRegistroIvaBase::setupUi(QWidget*) in listregistroivaview.o Ui_ListRegistroIvaBase::setupUi(QWidget*) in listregistroivaview.o Ui_RegistroIvaBase::setupUi(QWidget*) in registroivaview.o Ui_RegistroIvaBase::setupUi(QWidget*) in registroivaview.o "FichaBc::staticMetaObject", referenced from: __ZN7FichaBc16staticMetaObjectE$non_lazy_ptr in registroiva.o RegistroIvaView::staticMetaObjectin moc_registroivaview.o "FichaBc::~FichaBc()", referenced from: RegistroIva::~RegistroIva()in registroiva.o RegistroIva::~RegistroIva()in registroiva.o RegistroIva::~RegistroIva()in registroiva.o RegistroIva::~RegistroIva()in registroiva.o RegistroIva::RegistroIva(Empresa*, QWidget*)in registroiva.o "Asiento1::
Re: [CMake] Errors in OSX platform and ubuntu of a Qt app
Well, I _still_ don't have postgres SQL, but the following link error:
Ui_CobroPagoBase::setupUi(QWidget*)
leads me to believe that there is a missing include directory or link
directory in the cmake file that somehow you are getting away with on
Debian and not on OS X.
###
# Plugin for bulmacont#
###
#pluginregistrodeiva
set (plugin pluginregistrodeiva)
file(GLOB_RECURSE plugin_SRC *.c *.cpp *.cxx)
file(GLOB_RECURSE plugin_MOCS *.hpp *.h)
file(GLOB_RECURSE plugin_UIS *.ui)
> Note Changed order of following lines
set(QT_USE_QTASSISTANT true)
set(QT_USE_QTXML true)
###---> QT_USE_FILE needs the above variables set BEFORE calling the
INCLUDE (...)
INCLUDE( ${QT_USE_FILE} )
include_directories(
${QT_INCLUDE_DIR}
${PGSQL_INCLUDE_DIR}
${QT_QTXML_INCLUDE_DIR}
${QT_QTASSISTANT_INCLUDE_DIR}
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_BINARY_DIR}/bulmalib/src/
${CMAKE_SOURCE_DIR}/bulmalib/src/
${CMAKE_BINARY_DIR}/bulmacont/src/
${CMAKE_SOURCE_DIR}/bulmacont/src/)
# generate rules for building source files from the resources
#QT4_WRAP_CPP(plugin_MOC_SRCS ${plugin_MOCS})
# generate rules for building source files that moc generates
QT4_WRAP_UI(plugin_UIS_H ${plugin_UIS})
QT4_WRAP_CPP(plugin_MOC_SRCS ${plugin_MOCS})
#QT4_ADD_RESOURCES(plugin_RCC_SRCS ${plugin_RCCS})
### Not NEEDED.. QT_USE_FILE will add these for you
#ADD_DEFINITIONS(${QT_DEFINITIONS})
ADD_DEFINITIONS(-DQT_SHARED)
# build sources, moc'd sources, and rcc'd sources
add_library(${plugin} SHARED ${plugin_SRC} ${plugin_MOC_SRCS}
${plugin_UIS_H} ${plugin_SRCS} ${plugin_MOCS})
set_target_properties( ${plugin} PROPERTIES
SOVERSION "${BULMAGES_VERSION_MAJOR}.${BULMAGES_VERSION_MINOR}"
VERSION "${BULMAGES_VERSION}")
## QT_LIBRARIES will include the following libraries so you do not
have to specifically
## list them in the target_link_libraries function
# ${QT_QTGUI_LIBRARY}
# ${QT_QTASSISTANT_LIBRARY}
target_link_libraries(${plugin} bulmalib ${QT_LIBRARIES} $
{PGSQL_LIBRARIES})
install_targets(/lib/bulmacont/plugins ${plugin})
I do not see anything else that jumps out at me. If you can tell me
where to download the PostgreSQL for os x 10.4.11 Tiger (intel) I
might have some time to try the build.
--
Mike Jackson Senior Research Engineer
Innovative Management & Technology Services
On Dec 12, 2007, at 9:20 AM, Leopold Palomo-Avellaneda wrote:
A Dimecres 12 Desembre 2007 14:06, Mike Jackson va escriure:
I don't have Postgres SQL so I can not try your build on OS X.
only need the libpq with the /usr/include/postgresql/* includes
files. Please,
if you could do it I will thank you a lot.
Could
you post the link errors from the OS X machine? Maybe someone can be
of more help.
Generally I have few problems compiling my code on 64 bit linux and
OS X.
Well, the cmake works, but it fails at 34% when link a shared
library. At
Debian it doesn't fails. The user sent me the output that is below.
Regards,
Leo
###3
Scanning dependencies of target pluginregistrodeiva
[ 34%] Building CXX object bulmacont/plugins/pluginregistroiva/
CMakeFiles/pluginregistrodeiva.dir/moc_ui_cobropagobase.o
[ 34%] Building CXX object bulmacont/plugins/pluginregistroiva/
CMakeFiles/pluginregistrodeiva.dir/moc_ui_listregistroivabase.o
[ 34%] Building CXX object bulmacont/plugins/pluginregistroiva/
CMakeFiles/pluginregistrodeiva.dir/moc_ui_registroivabase.o
Linking CXX shared library libpluginregistrodeiva.dylib
Undefined symbols:
"aplinteligentesview::aplinteligentesview(Empresa*, QWidget*)",
referenced from:
linprevcobro::creaPago() in linprevcobro.o
"aplinteligentesview::setfechaasiento(QString)", referenced from:
linprevcobro::creaPago() in linprevcobro.o
"regivaprintview::regivaprintview(Empresa*, QWidget*)", referenced
from:
ListRegistroIvaView::boton_print() in
listregistroivaview.o
"BusquedaCuenta::BusquedaCuenta(QWidget*)", referenced from:
Ui_CobroPagoBase::setupUi(QWidget*) in cobropagoview.o
Ui_RegistroIvaBase::setupUi(QWidget*) in registroivaview.o
"aplinteligentesview::inicializa(int)", referenced from:
linprevcobro::creaPago() in linprevcobro.o
"FichaBc::FichaBc(Empresa*, QWidget*, QFlags)",
referenced from:
RegistroIva::RegistroIva(Empresa*, QWidget*)in registroiva.o
"aplinteligentesview::setvalores(QString, QString)", referenced
from:
linprevcobro::creaPago() in linprevcobro.o
linprevcobro::creaPago() in linprevcobro.o
linprevcobro::creaPago() in linprevcobro.o
linprevcobro::creaPago() in linprevcobro.o
"Asiento1View::muestraasiento(int)", referenced from:
ListLinPrevCobroView::contextMenu(int,
Re: [CMake] escaping!
Hi, Well, these don't answer much. The first message (from Andrew) mentions an option I have considered: writing everything on a script and calling the script. However, I thought it would be possible with cmake. The wiki just says: "You may need \\ instead of \ due to CMake argument processing. \" works fine in SET statements, but you may need \\\" in some CMake functions. It can get hairy. This section needs elaboration." And that explains absolutely nothing. That is precisely the problem I have and I tried many diferent things but none seemed to work. Now, on a note... this problem appeared after I had been trying to do something that I think can't be done with cmake. I will ask that question but I would like to know how to solve this one. Javier Sylvain Benner wrote: > >> I'm quite jaded about keeping CMakeLists.txt "simple." As far as I'm >> concerned, it should be as simple as the level of complication of your >> build. If I want encapsulation, I write a macro. Otherwise I'll just >> write straight CMake script, because I'd rather read CMake script than >> the docs of 5 different Unixy tools that all do their own kind of >> regular expression processing. >> > I second this. > We have a pretty big project and installer generation framework using > CMake technology and it is very valuable to learn and master CMake > scripting for a long-terme development. > If everything is done with CMake you get more consistency and an easy > and natural way to get access to your framework variables. > > Here is my advice: > First think about how to do it the CMake way,then if it's not doable > (which is pretty rare) do it with some other language. > > "man cmake" is your best friend ;-) > > --Sylvain > > ___ > 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] Errors in OSX platform and ubuntu of a Qt app
A Dimecres 12 Desembre 2007 16:00, Mike Jackson va escriure:
> Well, I _still_ don't have postgres SQL, but the following link error:
>
> Ui_CobroPagoBase::setupUi(QWidget*)
>
> leads me to believe that there is a missing include directory or link
> directory in the cmake file that somehow you are getting away with on
> Debian and not on OS X.
it's curious, why in debian works and not in OSX.
>
> ###
> # Plugin for bulmacont #
> ###
> #pluginregistrodeiva
>
> set (plugin pluginregistrodeiva)
>
> file(GLOB_RECURSE plugin_SRC *.c *.cpp *.cxx)
> file(GLOB_RECURSE plugin_MOCS *.hpp *.h)
> file(GLOB_RECURSE plugin_UIS *.ui)
>
> > Note Changed order of following lines
> set(QT_USE_QTASSISTANT true)
> set(QT_USE_QTXML true)
> ###---> QT_USE_FILE needs the above variables set BEFORE calling the
> INCLUDE (...)
> INCLUDE( ${QT_USE_FILE} )
>
I understand that I _must_ change this lines, using the set BEFORE the
INCLUDE( ${QT_USE_FILE} ) no?
[]
>
> ### Not NEEDED.. QT_USE_FILE will add these for you
> #ADD_DEFINITIONS(${QT_DEFINITIONS})
OK
> ADD_DEFINITIONS(-DQT_SHARED)
> # build sources, moc'd sources, and rcc'd sources
>
> add_library(${plugin} SHARED ${plugin_SRC} ${plugin_MOC_SRCS}
> ${plugin_UIS_H} ${plugin_SRCS} ${plugin_MOCS})
>
>
> set_target_properties( ${plugin} PROPERTIES
>SOVERSION "${BULMAGES_VERSION_MAJOR}.${BULMAGES_VERSION_MINOR}"
>VERSION "${BULMAGES_VERSION}")
>
> ## QT_LIBRARIES will include the following libraries so you do not
> have to specifically
> ## list them in the target_link_libraries function
> # ${QT_QTGUI_LIBRARY}
> # ${QT_QTASSISTANT_LIBRARY}
>
> target_link_libraries(${plugin} bulmalib ${QT_LIBRARIES} $
> {PGSQL_LIBRARIES})
> install_targets(/lib/bulmacont/plugins ${plugin})
ok.
three things:
1) set before the QT_USE_FILE
2) not need to put QT_DEFINITIONS
3) only need to put QT_LIBRARIES
>
> I do not see anything else that jumps out at me. If you can tell me
> where to download the PostgreSQL for os x 10.4.11 Tiger (intel) I
> might have some time to try the build.
ok, question sent to the boy that is working with OSX.
Thanks, thanks, thanks,
Best regards,
Leo
PS I have a lot of files to change . :-(
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
On Dec 12, 2007 12:33 AM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> Tristan, I have been slow to respond to your e-mail because it took a long
> time to investigate the java problems created by your patch. Details,
> below.
>
> On 2007-12-11 10:59+0100 Tristan Carel wrote:
>
> > On Dec 10, 2007 8:58 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> >> Tristan, since you do not encounter this problem, are you doing something
> >> qualitatively different than above in your CMakeLists.txt file?
> >
> [...]
>
>
> N.B. that patch did not work at all unless I changed
>
> @@ -48,9 +49,15 @@
>
> to
>
> @@ -48,9 +49,14 @@
>
Ooops!
>
> [...]
>
> Although it appears to be redundant since "%module plplotc" is specified in
> plplotcmodules.i, I added the following line to the CMake code
>
> set_source_files_properties(plplotcmodule.i
> PROPERTIES SWIG_MODULE_NAME plplotc
> )
>
> > I would be glad to know if it resolves your dependencies problem.
>
> Yes, it does for the python case, but can you explain why this patched
> version work (no gratuitous rebuilds) when "%module plplotc" alone does not
> work with the unpatched version?
>
In Python specific case, with "%module plplotc" alone, UseSwig.cmake
creates the following make rule:
plplotcmodulePYTHON_wrap.c plplotcapi.py: plplotcapi.i
/usr/bin/swig ...
To get module's name, UseSwig.cmake does not look in swig files'
content: plplotcapi.py is deduced from the swig filename. So when
module's name specified with "%module " directive differs
from the swig filename, you can tell `UseSwig.cmake' the real module's
name with the `SWIG_MODULE_NAME' property.
So that if plplotcapi.py is (accidently) removed, `make' runs `swig'
to re-create it.
> The remainder of this e-mail concerns the java compilation problems that
> showed up with your patched version of UseSwig.cmake.
>
> Your current approach for compiling java files does not work since there is
> a whole boatload of *.java files generated by swig as well as some special
> files which we need to compile as well. For the PLplot case the complete
> list of java files (all but those marked as hand-crafted or configured are
> generated by swig) is the following:
>
> bindings/java/PLStream.java (hand-crafted)
>
> in the source tree and
>
> bindings/java/PLGraphicsIn.java
> bindings/java/plplotjavac.java
> bindings/java/plplotjavacConstants.java
> bindings/java/plplotjavacJNI.java
> bindings/java/config.java (configured)
>
> in the build tree.
>
> The plplotjavacConstants.java file can be taken care of by making the
> following change to your patched UseSWIG.cmake:
>
> -SET(SWIG_JAVA_EXTRA_FILE_EXTENSION "JNI.java" ".java")
> +# Order is important
> +SET(SWIG_JAVA_EXTRA_FILE_EXTENSION "JNI.java" "Constants.java" ".java")
>
> Also, when compiling plplotjavacConstants.java, the results of
> the plplotjavacJNI.java compilation cannot be found unless you
> add
>
> ${CMAKE_BINARY_DIR}/CMakeFiles/plplotjavac_wrap.dir
>
> to the list of directories referenced by INCLUDE_DIRECTORIES. There is no
> guarantee in the future that this directory prefix will continue to be used
> to store the class files so this change must be classified as a temporary
> workaround. See below for a better approach which controls the location
> where the class files are located.
building wrappers generated by swig is not UseSwig.cmake's duty. But
to know which files are created by swig, I guess this is mandatory.
`UseSwig.cmake' should prevent user to painfully manage list of
generated wrappers, like you do to compile java bindings.
For example if you delete one of the generated java file, `make'
should re-run swig, which is not currently the case.
About the weird error you have with java:
Relative to the way I have used swig + java, I guessed the line:
SET(SWIG_JAVA_EXTRA_FILE_EXTENSION "JNI.java" ".java")
Unfortunately with plplot, some others are created.
For the moment, swig does not provide list of created files. With
option -MM, swig writes to standard output:
/tmp/plplot/bindings/java/plplotjavac_wrap.c: \
/tmp/plplot/bindings/java/plplotjavac.i \
/tmp/plplot/bindings/swig-support/plplotcapi.i
This is good actually, as we can determine list of dependencies. But
not good enough as we don't know the list of generated wrappers. This
feature of Swig is not currently used by `UseSwig.cmake', but we will
be soon to get exact dependencies.
> Additionally, there is the showstopper problem of the swig-generated file
> PLGraphicsIn.java. I only have a superficial knowledge of swig and java,
> but I believe that file is generated because our API *.i file has a struct
> defined that is called PLGraphicsIn. Anyhow, it appears in the Java case
> that swig-generated files will have a variety of names depending on the *.i
> internals of each separate project.
>
> Furthermore, there is the showstopper issue of the PLplot-specific java file
> called PLStream.java in the source tree, and our configured java file called
> config.java in the build tre
Re: [CMake] Swig dependencies not being tested?
On 2007-12-12 17:17+0100 Tristan Carel wrote: On Dec 12, 2007 12:33 AM, Alan W. Irwin <[EMAIL PROTECTED]> wrote: [...] Tristan, if you decide to create a patch for UseSwig.cmake that does all that for the java case, I would be happy to test it. However, if it is possible to solve the original gratuitous C rebuild issue for the java interface case without compiling the java files, then that might greatly reduce the changes you have to do for UseSwig.cmake. As we can't get the exact list of generated files by swig, we won't try to guess it, so won't try to build them too :) I have added an entry at CMake BT: http://www.cmake.org/Bug/bug_view_page.php?bug_id=6151 The patch is sensibly different from the previous one: it mainly remove the spurious entry SET(SWIG_JAVA_EXTRA_FILE_EXTENSION "JNI.java" ".java") It fixes unecessary rebuilds, whatever the language target. I just tried your latest patch for UseSWIG.cmake, and indeed it works fine (original build is fine and redoing make does not rebuild anything) with PLplot if I add set_source_files_properties(plplotjavac.i PROPERTIES SWIG_MODULE_NAME plplotjavac ) for the java case and set_source_files_properties(plplotcmodule.i PROPERTIES SWIG_MODULE_NAME plplotc ) for the python case. Thanks a lot for figuring out this unnecessary rebuild issue for swig with such a minimalistic patch! I don't have CVS write access on the modules repository. I will ask Bill for it. Good move. 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
[CMake] Linking unit tests
Hi, I'm trying to build a collection of libraries, each with a set of unit tests. In CMakeLists.txt, I use `add_library` to create the main target and `add_executable` to generate a test runner for each library. Then I use `target_link_libraries` to link each test runner to it's corresponding library. The problem with this solution is that I can only test the interfaces that are exported from the library. I really want to be able to test all of the units, including internal classes. But how can I do this with CMake? In the past (when I was using SCons) I compiled the source files into object files, and then linked the same object files into both the test executable and the shared library. Is it possible to do this with CMake? Many thanks, Marcus ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compilation speed with CMake/NMake combination, making it faster?
Eric Noulard wrote: 2007/12/11, Jason Stewart <[EMAIL PROTECTED]>: This is not scientific but I wrote a quick perl script to compile a simple library that we use (GCTPc). It consists of 70 C files with most of the files between 5K and 6K, a few are as large as 70K. The script just uses the time() function to grab the elapsed seconds and runs three tests. The first runs one cl.exe process with all 70 files with the '-c' flag to only compile. The second compiles each C file with it's own invocation of cl.exe. The last repeats the first, but with the new, experimental, '/MP' flag that does multiprocessor builds. I get the following times for these files: all files : 2 seconds single files : 7 seconds mp build : 1 second I repeated this test with a set of 15 C++ files that are larger with template code and that take significantly longer and I got the following times: all files : 60 seconds single files : 78 seconds mp build : 51 seconds So, even on the single processor build the single invocation is almost 25% faster. Take it all with a grain of salt. I'm not a big MS Platform user but I like the idea of compilation speed-up very much. I personnally use ccache (http://ccache.samba.org/) on Linux + gcc and there is x2 up to x4 _SPEEDUP_ (when recompiling since initial compilation is slower) on a C++ project with 50+ files with moderate template usage. Yes, recompiling goes faster, but if you actually have made any changes to the source code (which is often the case when you're compiling ;-)) then ccache won't give you anything. Most people I've seen claim that ccache is useful are people who are stuck with a build system with broken dependencies who need to do "make clean" a lot. ;-) Actually, ccache comes in its best light when you can use it for sharing build-results. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Logarithms in MATH expressions
On 12/12/07, Martin Lütken <[EMAIL PROTECTED]> wrote:
>
> Anyone who knows wheter it's possible to calculate logarithms in MATH
> expressions in CMake?
>
Would like a log2 or alternatively "ln" (natural).
>
Not directly, no.
The CMake MATH EXPR parser handles the following tokens:
Decimal numbers:
[0-9][0-9]*
And the basic C/C++ math, bit-operation and grouping operators:
"+"
"-"
"*"
"/"
"%"
"\|"
"&"
"^"
"~"
"<<"
">>"
"("
")"
See the files CMake/Source/cmExpr* for more info...
HTH,
David
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] What's happening to CMake ??? Please help !!!
Thanks David, I'm going to try it right away ... Regards Cem _ From: David Cole [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 9:34 PM To: Cem DEMiRKIR Cc: CMake Mailing List Subject: Re: [CMake] What's happening to CMake ??? Please help !!! CMake 2.4.4 had some serious flaws and was only available for a very short time before being fixed by 2.4.5 Update to the latest CMake release (2.4.7) and try again. And don't forget to start over with an empty binary directory after updating CMake... HTH, David On 12/11/07, Cem DEMiRKIR <[EMAIL PROTECTED]> wrote: Hello CMake users & developers, I've been trying to build ITK on my machine, and obviously is not related to what is built, and CMake produces some errors at the configuration step. Perhaps someoneelse has already encountered similar type of problem ? My setup: Windows XP, ITK 3.4.0 Latest Release, CMake 2.4.4, Visual Studio .NET 2005 w/ Visual C++ 8 At first I've observed the following CMake Errror message box and then a lot of errors coming up when I choose OK. CMake Error: Unable to find executable for TRY_RUN: tried "Z:\Libraries\Insight\bin/CMakeTmp/cmTryCompileExec.exe" and "Z:\Libraries\Insight\bin/CMakeTmp/Debug/cmTryCompileExec.exe" and "Z:\Libraries\Insight\bin/CMakeTmp/Development/cmTryCompileExec.exe". [CMake is correct; these files do not exist, but the log indicates no error for the building of these executables.] I've compiled previous version of ITK, or VTK, etc. without any problem before, but after deleting old one and trying to build the latest release, I've got these errors. I'd be grateful to anyone who help me resolve this problem ? Sincerely Cem DEMiRKIR ___ 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] What's happening to CMake ??? Please help !!!
Hi David, Unfortunately it doesn't work. It produces the same errors. Regards Cem DEMiRKIR _ From: David Cole [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 9:34 PM To: Cem DEMiRKIR Cc: CMake Mailing List Subject: Re: [CMake] What's happening to CMake ??? Please help !!! CMake 2.4.4 had some serious flaws and was only available for a very short time before being fixed by 2.4.5 Update to the latest CMake release (2.4.7) and try again. And don't forget to start over with an empty binary directory after updating CMake... HTH, David On 12/11/07, Cem DEMiRKIR <[EMAIL PROTECTED]> wrote: Hello CMake users & developers, I've been trying to build ITK on my machine, and obviously is not related to what is built, and CMake produces some errors at the configuration step. Perhaps someoneelse has already encountered similar type of problem ? My setup: Windows XP, ITK 3.4.0 Latest Release, CMake 2.4.4, Visual Studio .NET 2005 w/ Visual C++ 8 At first I've observed the following CMake Errror message box and then a lot of errors coming up when I choose OK. CMake Error: Unable to find executable for TRY_RUN: tried "Z:\Libraries\Insight\bin/CMakeTmp/cmTryCompileExec.exe" and "Z:\Libraries\Insight\bin/CMakeTmp/Debug/cmTryCompileExec.exe" and "Z:\Libraries\Insight\bin/CMakeTmp/Development/cmTryCompileExec.exe". [CMake is correct; these files do not exist, but the log indicates no error for the building of these executables.] I've compiled previous version of ITK, or VTK, etc. without any problem before, but after deleting old one and trying to build the latest release, I've got these errors. I'd be grateful to anyone who help me resolve this problem ? Sincerely Cem DEMiRKIR ___ 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] Compilation speed with CMake/NMake combination, making it faster?
2007/12/12, Jesper Eskilson <[EMAIL PROTECTED]>: > Eric Noulard wrote: > > I'm not a big MS Platform user but I like the idea > > of compilation speed-up very much. > > > > I personnally use ccache (http://ccache.samba.org/) > > on Linux + gcc and there is x2 up to x4 _SPEEDUP_ > > (when recompiling since initial compilation is slower) > > on a C++ project with 50+ files with moderate template usage. > > Yes, recompiling goes faster, but if you actually have made any changes > to the source code (which is often the case when you're compiling ;-)) > then ccache won't give you anything. Your experience may be different but I can assure you that when I'm doing reasonable source code changes I do see speed-up. The fact is when you've just added a bunch of functions/method to one (or better several) (non-templated) class(es) you do not change the header file very often but you do modify the implementation a bunch of time before you are finally ok with it. May be it's because I'm not the write once compile once guy :=) In that scenario (my _current_ common case) I really get noticeable speed-up. I've never measured it but I did "feel" it very well because I was developing in 2 differents places, one with ccache and the second without it. I promptly installed ccache on the second when I realised that. Another ccache-winning scenario is when you are in the process of "releasing" your software, most of the time I'm doing almost 2,3,4... builds before I get the final released one. Most of the time I do recompile from scratch even if it was a packaging issue (i.e. no source modification). > Most people I've seen claim that ccache is useful are people who are > stuck with a build system with broken dependencies who need to do "make > clean" a lot. ;-) I'm using CMake + Unix Makefile generator. I don't think it has so broken dependencies or has it? :=) > Actually, ccache comes in its best light when you can use it for sharing > build-results. I did not experienced that but for myself, I usually have several source/tree and build/tree for differents version of the same software. one tree for common dev one tree for testing foreign patch one tree for release ... Those different trees shares the ccache cache. I think it saves me a lot of header preprocessing. Those are just comments for my own use case. I'm not trying to convince anybody that ccache is a "must have" but I now think it's worth trying. -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] escaping!
On Dec 12, 2007 10:09 AM, Javier Gonzalez <[EMAIL PROTECTED]> wrote: > Hi, > > Well, these don't answer much. The first message (from Andrew) mentions > an option I have considered: writing everything on a script and calling > the script. > > However, I thought it would be possible with cmake. "It" probably is. But you know, these quoting and escape issues are... really really boring. > The wiki just says: > "You may need \\ instead of \ due to CMake argument processing. \" works > fine in SET statements, but you may need \\\" in some CMake functions. > It can get hairy. This section needs elaboration." Yeah, I wrote that on the wiki. Nobody paid me to do it. I figured it was better than the complete absence of information on the wiki that previously existed. > And that explains absolutely nothing. You're absolutely right. My comment on the wiki says so. It's a placeholder. The usual way to deal with such things is to pore over the mailing list archives and hack, hack, hack until you come up with an answer. Then, if your labor yields a clear solution, and you still have energy left over, you can improve the wiki documentation for the next poor slob who happens by. But nobody's paying anyone to do that, so there's always this tradeoff of whether you're going to pay attention to other people's needs, or your own needs. I've got my own needs to worry about right now. Such is the nature of open source. Call me jaded, but part of my expectation in open source is that when $0 is changing hands, people will do some of the explaining and hacking themselves. I've reiterated / harped on the need for "Chapter oriented" documentation for a long time. That's how you'd properly reposit information about quoting, escape, and VERBATIM behavior, so that other people can find and utilize it. But we don't have the infrastructure for that at present. Nothing's stopping anyone from overhauling the wiki and making it chapter oriented, except for the fact that it's a ton of work that nobody wants to do for $0. The CMake 2.6 documentation in CVS is a significant improvement over the 2.4.7 documentation. It has web hyperlinks for commands, it breaks Modules into their own section, and CMake variables are actually getting documented. These are big improvements. But there's still nothing chapter oriented, so finding certain kinds of information will continue to be problematic. I'm really glad there's as much improvement as there is though. The documentation is clearly moving forwards. > That is precisely the problem I > have and I tried many diferent things but none seemed to work. > > Now, on a note... this problem appeared after I had been trying to do > something that I think can't be done with cmake. I will ask that > question but I would like to know how to solve this one. Through hacking, one finds the bleeding edge of CMake. When I've found the bleeding edge, I try to obtain 1 of 2 results: - an approach that works. If it's hairy, I may file a feature request. - a bug that's reproducible. In which case, I file a bug report. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] specify output directory when running from the command line
When running CMake from the command line, how can I specify the directory to put the output files in. Thanks. Jesse ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
A set of custom rules to copy files from the source tree to the build tree
is screwing up for parallel builds on Debian testing with cmake 2.4.7. The
parallel builds are done with "make -j 2" on a core duo system (Intel E6550
2.33 MHz). I am not sure whether the issue is something wrong with our
CMake code, a bug in CMake, or a bug in GNU make, and I would appreciate
your comments to help sort out the possibilities.
Here is the cmake stanza to set up the custom rules and overall custom
target that depends on those rules:
# Copy file and scripts to the binary directory if different to the
# source directory. Needed for ctest, but also so the tclIndex file
# is generated in the binary tree not the source tree.
if(NOT CMAKE_CURRENT_BINARY_DIR STREQUAL "${CMAKE_CURRENT_SOURCE_DIR}")
set(tclIndex_WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
set(tclIndex_DEPENDS)
foreach(file ${tcl_SCRIPTS} ${tcl_FILES})
set(
tclIndex_DEPENDS
${tclIndex_DEPENDS}
${CMAKE_CURRENT_BINARY_DIR}/${file}
)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${file}
COMMAND ${CMAKE_COMMAND} -E copy
${CMAKE_CURRENT_SOURCE_DIR}/${file} ${CMAKE_CURRENT_BINARY_DIR}
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${file}
)
endforeach(file ${tcl_SCRIPTS} ${tcl_FILES})
add_custom_target(tcl_examples ALL DEPENDS ${tclIndex_DEPENDS})
else(NOT CMAKE_CURRENT_BINARY_DIR STREQUAL "${CMAKE_CURRENT_SOURCE_DIR}")
set(tclIndex_DEPENDS ${tcl_FILES} ${tcl_SCRIPTS})
set(tclIndex_WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
endif(NOT CMAKE_CURRENT_BINARY_DIR STREQUAL "${CMAKE_CURRENT_SOURCE_DIR}")
For the case of separate build tree, the resulting Makefile stanzas look
like the following :
examples/tcl/CMakeFiles/tclIndex_examples_tcl: examples/tcl/x01
examples/tcl/CMakeFiles/tclIndex_examples_tcl: examples/tcl/x02
...etc.
examples/tcl/x01: /home/software/plplot_cvs/HEAD/plplot_cmake/examples/tcl/x01
$(CMAKE_COMMAND) -E cmake_progress_report
/home/software/plplot_cvs/HEAD/build_dir/CMakeFiles $(CMAKE_PROGRESS_1)
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold
"Generating x01"
cd /home/software/plplot_cvs/HEAD/build_dir/examples/tcl &&
/usr/bin/cmake -E copy /home/software/plplot_cvs/HEAD/plplot_cmake/examples/tcl/x01
/home/software/plplot_cvs/HEAD/build_dir/examples/tcl
examples/tcl/x02: /home/software/plplot_cvs/HEAD/plplot_cmake/examples/tcl/x02
$(CMAKE_COMMAND) -E cmake_progress_report
/home/software/plplot_cvs/HEAD/build_dir/CMakeFiles $(CMAKE_PROGRESS_1)
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold
"Generating x02"
cd /home/software/plplot_cvs/HEAD/build_dir/examples/tcl &&
/usr/bin/cmake -E copy /home/software/plplot_cvs/HEAD/plplot_cmake/examples/tcl/x02
/home/software/plplot_cvs/HEAD/build_dir/examples/tcl
...etc.
This works fine for serial builds (make -j 1), but for parallel builds
(make -j 2) there is some problem with the interpretation of the
dependencies which means the copy commands are sometimes duplicated.
x01 and x02 were copied correctly, but the x03, x04, and x05 files
were copied twice with the latter double copy causing a severe error.
Here is part of the "make -j 2" output:
make -f examples/tcl/CMakeFiles/tclIndex_examples_tcl.dir/build.make
examples/tcl/CMakeFiles/tclIndex_examples_tcl.dir/build
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/build_dir'
/usr/bin/cmake -E cmake_progress_report /home/software/plplot_cvs/HEAD/build_dir/CMakeFiles
[ 22%] Generating x01
cd /home/software/plplot_cvs/HEAD/build_dir/examples/tcl && /usr/bin/cmake -E
copy /home/software/plplot_cvs/HEAD/plplot_cmake/examples/tcl/x01
/home/software/plplot_cvs/HEAD/build_dir/examples/tcl
/usr/bin/cmake -E cmake_progress_report /home/software/plplot_cvs/HEAD/build_dir/CMakeFiles
[ 22%] make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/build_dir'
/usr/bin/cmake -E cmake_progress_report
/home/software/plplot_cvs/HEAD/build_dir/CMakeFiles 18
Generating x02
cd /home/software/plplot_cvs/HEAD/build_dir/examples/tcl && /usr/bin/cmake -E
copy /home/software/plplot_cvs/HEAD/plplot_cmake/examples/tcl/x02
/home/software/plplot_cvs/HEAD/build_dir/examples/tcl
[ 23%] Built target make_documentation
make -f examples/tcl/CMakeFiles/tcl_examples.dir/build.make
examples/tcl/CMakeFiles/tcl_examples.dir/build
/usr/bin/cmake -E cmake_progress_report /home/software/plplot_cvs/HEAD/build_dir/CMakeFiles
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/build_dir'
/usr/bin/cmake -E cmake_progress_report /home/software/plplot_cvs/HEAD/build_dir/CMakeFiles
[ 23%] [ 23%] Generating x03
cd /home/software/plplot_cvs/HEAD/build_dir/examples/tcl && /usr/bin/cmake -E
copy /home/software/plplot_cvs/HEAD/plplot_cmake/examples/tcl/x03
/home/software/plplot_cvs/HEAD/build_dir/examples/tcl
Generating x03
cd /home/software/plplot_cvs/HEAD/build_dir/examples/tcl && /usr/bin/cmake -E
c
Re: [CMake] specify output directory when running from the command line
I think the practice,with both cmake and ccmake, is to invoke cmake inside the directory you want the output. So a typical drill is mkdir mybuilddir cd mybuilddir ccmake mysourcedir I use CMakeSetup all the time so this isn't an issue to me. Debates about making cmake more command line friendly appear from time to time. I'll let others debate the merits of this one. I do note that when I typed "cmake --help" it wasn't entirely clear to me where I'd specify an output directory, or if I would. I just happen to know the expected usage. I would say that (c)cmake --help is under-documented on this point. Cheers, Brandon Van Every On Dec 12, 2007 8:08 PM, Jesse Corrington <[EMAIL PROTECTED]> wrote: > When running CMake from the command line, how can I specify the directory to > put the output files in. Thanks. > > Jesse > > ___ > 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] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2007-12-12 17:10-0800 Alan W. Irwin wrote: A set of custom rules to copy files from the source tree to the build tree is screwing up for parallel builds on Debian testing with cmake 2.4.7. The parallel builds are done with "make -j 2" on a core duo system (Intel E6550 2.33 MHz). Before anybody else spots that, I have to say that system sure would be slow! I meant GHz, of course. :-) 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
