[cmake-developers] Multiple dependent install(EXPORT) sets
On 11/22/2011 9:31 AM, Stephen Kelly wrote: CMake Error: INSTALL(EXPORT twoDeps ...) includes target libtwo which requires target libone that is not in the export set. How can we resolve this? http://public.kitware.com/Bug/view.php?id=12588 Brad asked to bring this up on the list for discussion. Additional CMake development is needed to support this. We need to introduce the notion of multiple dependent install(EXPORT) sets. I think the commands will look something like this: add_library(A ...) add_library(B ...) target_link_libraries(B A) install(TARGETS A ... EXPORT ExportA) install(TARGETS B ... EXPORT ExportB) install(EXPORT ExportA ...) install(EXPORT ExportB DEPENDS ExportA ...) The DEPENDS ExportA option to install(EXPORT) on the last line will need to be added and implemented. We will have to require that the install(EXPORT) commands be invoked in dependency order (ex. A before B). That way when the command installing ExportB is writing library B's dependency on A, it can transform the name using the options that had been given to the install command for ExportA, such as its NAMESPACE. Furthermore, the targets file generated for ExportB will need to include() the file generated for ExportA using the DESTINATION given to the latter to make its targets available. Take a look at cmInstallExportGenerator, cmExportInstallFileGenerator, and cmGlobalGenerator's ExportSets member. Some of them will need to be refactored to allow an export set to refer to other exports sets as dependencies. The check in cmExportFileGenerator::SetImportLinkProperty for availability of a target's dependencies will have to be replaced with a lookup that follows the export set's dependencies. If the dependency belongs to another set, that other set's prefix must be used when referring to the target. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Multiple dependent install(EXPORT) sets
Brad King wrote: On 11/22/2011 9:31 AM, Stephen Kelly wrote: CMake Error: INSTALL(EXPORT twoDeps ...) includes target libtwo which requires target libone that is not in the export set. How can we resolve this? http://public.kitware.com/Bug/view.php?id=12588 Brad asked to bring this up on the list for discussion. Additional CMake development is needed to support this. We need to introduce the notion of multiple dependent install(EXPORT) sets. I think the commands will look something like this: add_library(A ...) add_library(B ...) target_link_libraries(B A) install(TARGETS A ... EXPORT ExportA) install(TARGETS B ... EXPORT ExportB) install(EXPORT ExportA ...) install(EXPORT ExportB DEPENDS ExportA ...) The DEPENDS ExportA option to install(EXPORT) on the last line will need to be added and implemented. We will have to require that the install(EXPORT) commands be invoked in dependency order (ex. A before B). That way when the command installing ExportB is writing library B's dependency on A, it can transform the name using the options that had been given to the install command for ExportA, such as its NAMESPACE. Furthermore, the targets file generated for ExportB will need to include() the file generated for ExportA using the DESTINATION given to the latter to make its targets available. And its FILE presumably, but why? This ties in to the question of whether find_package(B) should find the dependencies of B: case 1: project(big_project) find_package(A) // Uses AConfig.cmake, which includes ATargets.cmake find_package(B) // Uses BConfig.cmake, which includes BTargets.cmake case 2: project(big_project) find_package(B) // Uses BConfig.cmake, which includes BTargets.cmake // and ATargets.cmake, but there was no find_package(A), // so this is broken anyway. case 3: project(big_project) find_package(B) // Uses BConfig.cmake, which runs find_package(A), // includes BTargets.cmake and ATargets.cmake, despite the // fact that, find_package(A) has the effect of including it // anyway. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Multiple dependent install(EXPORT) sets
On 11/22/2011 10:03 AM, Stephen Kelly wrote: Brad King wrote: We will have to require that the install(EXPORT) commands be invoked in dependency order (ex. A before B). That way when the command installing ExportB is writing library B's dependency on A, it can transform the name using the options that had been given to the install command for ExportA, such as its NAMESPACE. This is required because ExportB will create an imported target for library B and that imported target will list its dependency on an imported target for library A. What is that imported target called? Where is it defined? Only ExportA knows, and then only after its install(EXPORT) has been called. Furthermore, the targets file generated for ExportB will need to include() the file generated for ExportA using the DESTINATION given to the latter to make its targets available. And its FILE presumably, but why? This ties in to the question of whether find_package(B) should find the dependencies of B: We could leave this part out and leave it up to the Config.cmake file author to ensure ExportA's targets file is loaded when ExportB's targets file is loaded. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
On Wednesday 02 November 2011, David Faure wrote:
On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
On Monday 31 October 2011, David Faure wrote:
This is a typical (kde) case where the .cpp incudes the .moc, for the
object defined in the .h.
Shouldn't it include moc_kauthactionwatcher.cpp ?
No, that's for the case where the qobject is in the .cpp file.
Is this really a typical case, i.e. is that done in many places ?
Yes. Just grep for moc includes in kde...
I thought the rule is that if there is a include foo.moc, the Q_OBJECT
is in the same cpp file.
No, it's the other way around, in KDE.
$ grep Q_OBJECT kautosavefile.*
kautosavefile.h:Q_OBJECT
$ grep moc kautosavefile.cpp
#include kautosavefile.moc
If it did additionally other things, this was more or less
accidentially.
But it was the way kdesupport/automoc always worked, on purpose, not
accidentally.
OK, more precisely: it didn't care what the name of the included moc
file was, what mattered was, where is Q_OBJECT being used.
As the kde4automoc.cpp code says: when parsing the .cpp file:
// If the moc include is of the moc_foo.cpp style we expect the Q_OBJECT
class // declaration in a header file.
// If the moc include is of the foo.moc style we need to look for a
Q_OBJECT // macro in the current source file, if it contains the macro
we generate the // moc file from the source file, else from the header.
The logic which is currently implemented is:
1. if foo.cpp includes foo.moc, run moc on foo.cpp and generate foo.moc
That should depend on if foo.cpp actually says Q_OBJECT or not.
Otherwise this .moc should be created from the header file. Not much
point in running moc over a .cpp that doesn't define a Q_OBJECT :)
2. run moc on all header files bar.h which contain Q_OBJECT and
generate moc_bar.cpp from them
That could be moc_bar.cpp or bar.moc depending on which one is included.
(which in detail means:
2.1 for every included moc_xyz.cpp (no matter in which file), search
for a corresponsing xyz.h/hxx/hpp file and run moc on it
2.2 for every bar.cpp file, check whether there is a corresponding
bar.h/hpp/hxx file and collect it
2.3 check for a Q_OBJECT macro in all collected header files and all
header files listed explicitely as a source for the target, and run moc
on them. If the resulting moc_xyz.cpp file has not been included in any
source file, include it intargetname_automoc.cpp, which is built as
part of the target )
Step 2.2 already involves guessing, which I don't like.
Beside that, IMO these are clear rules, which are easy to understand.
With the old behaviour it was actually ambigous:
foo.h:
class Foo
{
Q_OBJECT
};
foo.cpp:
Foo::Foo() {}
#include foo.moc
#include moc_foo.cpp
This would have generated twice the same moc file, I think. IMO this is
really confusing.
Well there is no reason to include both, unless you have Q_OBJECT in the
.cpp file too :-)
Now it is simple: foo.moc from foo.cpp, moc_foo.cpp from foo.h.
If this is really done in many places in KDE, I'll add some workaround,
but I think the default behaviour should stay as it is now in cmake
git.
How does qmake handle such cases ?
Checking
Indeed qmake expects moc_foo.cpp for the standard case (Q_OBJECT in
header). This is why kde4automoc was made to support both moc filenames,
so that it could be compatible with the kde way of doing it (foo.moc)
and with the qmake way of doing it (moc_foo.cpp).
Oh well, if you want to stick to that we'll change all of KDE, for the
benefit of a clearer future indeed... At least it won't be an source
incompatible change for app developers since they will have to enable
CMAKE_AUTOMOC to get into this situation. Merely upgrading cmake or KDE
(even to frameworks 5) won't trigger it. OK not exactly,
find_package(kde4) will stop working so they will -have- to port to
CMAKE_AUTOMOC, it will be the only solution available...
Please give the RestoreAutmocKDECompatibility branch on cmake stage a
try. It should work again, but print a warning if a file includes a
moc_foo.cpp, but no foo.moc, and contains a Q_OBJECT macro.
For Qt5 I'd prefer to not support that anymore.
I.e. moc_foo.cpp - header, foo.moc - source file.
Alex
I tried that branch.
I think I merged it into next in the meantime.
It doesn't build the frameworks branch for me. Does it work for you?
I haven't actually tried, I was relying on the frameworks developers (e.g.
you) for that :-)
In CMake/Tests/QtAutomoc/ there are several cases tested, actually I think all
I could think of.
Using Qt5 or Qt4 ?
There seems to be several problems:
* KDE does include foo.moc if it wants the
Re: [cmake-developers] Multiple dependent install(EXPORT) sets
On Tuesday 22 November 2011, Brad King wrote: On 11/22/2011 10:03 AM, Stephen Kelly wrote: Brad King wrote: We will have to require that the install(EXPORT) commands be invoked in dependency order (ex. A before B). That way when the command installing ExportB is writing library B's dependency on A, it can transform the name using the options that had been given to the install command for ExportA, such as its NAMESPACE. This is required because ExportB will create an imported target for library B and that imported target will list its dependency on an imported target for library A. What is that imported target called? Where is it defined? Only ExportA knows, and then only after its install(EXPORT) has been called. Yes. Where/why is it actually necessary to split libraries installed from one package into multiple Config.cmake files ? This is now to install separate libraries from a big kdelibs, right ? Maybe we (KDE) simply shouldn't do this, and just start with it once the big modules are broken into separate parts. Then each of the smaller parts can install a Config.cmake file for all its libraries. If e.g. libkgui depends on libkcore, currently those two targets would exist in one project, but installed as two export sets. Once they are separated into two projects, then libkgui depends already on the imported target KDE::kcore (or how it is named), and referencing this in its Targets.cmake file works fine. We do this already with Qt4. Furthermore, the targets file generated for ExportB will need to include() the file generated for ExportA using the DESTINATION given to the latter to make its targets available. And its FILE presumably, but why? This ties in to the question of whether find_package(B) should find the dependencies of B: We could leave this part out and leave it up to the Config.cmake file author to ensure ExportA's targets file is loaded when ExportB's targets file is loaded. Yes. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On 11/22/2011 06:20 PM, Alexander Neundorf wrote: Using Qt5 or Qt4 ? Qt4. There seems to be several problems: * KDE does include foo.moc if it wants the header file to be moc'd. This is 'incorrect' compared to what qmake expects, which would be a moc_foo.cpp include. Yes. * Some places in KDE use include moc_foo.cpp 'correctly', but there are only about 10 occurrences. The current automoc tool seems to handle that, as does cmake 2.8.6 apparently. I thought about this. There are 4 constellations, and only one constellation where things can break: * foo.cpp includes neither foo.moc nor moc_foo.cpp. No problem. Sort of. There are cases where the moc file must be included in the cpp file (see below). But this removal of includes is what we should aim for in KDE. I think if the options are: 1) Introduce odd hacky KDE specific workarounds to CMake 2) Remove the problematic includes from KDE files in the frameworks branch I will side with option 2). CMAKE_AUTOMOC is not used in KDE4. The feature is only really relevant to non KDE Qt4 users. Let's just 'fix the bug' in the frameworks iteration of kdelibs. * if foo.cpp includes both foo.moc and moc_foo.cpp, then both foo.h and foo.cpp will be moc'ed, and it doesn't matter which one is for which. No problem. It seems there is a test missing for this case. Yes. * if foo.cpp includes only foo.moc, then foo.cpp will be moc'ed. This may be unnecessary, but shouldn't create problems. If foo.h also needs to be moc'ed, it will be, and the resulting moc_foo.cpp will be included in the target_automoc.cpp file. So it should also work. This is Tests/QtAutomoc/codeeditor.cpp Sort of. There are cases where the moc file must be included in the cpp file, because it needs definitions from the .h file. (eg, use of the Q_PRIVATE_SLOT macro). If a KDE developer included foo.moc expecting that to be the result of moc'ing the .h file, the build will fail. In this case, foo.cpp needs to be fixed to include moc_foo.cpp instead. I don't think CMake should introduce a hack for this. * problematic case: if foo.cpp includes only moc_foo.cpp, then cmake will check whether foo.cpp contains Q_OBJECT. If it does, it will: ** fail with Qt5, stating that foo.cpp contains Q_OBJECT but does not include foo.moc, so it can't work I think this is fine. ** warn with Qt4 that it will run moc on foo.cpp instead of foo.h to generate moc_foo.cpp This is Tests/QtAutomoc/blub.cpp * KDE does include foo_test.moc in foo_test.cpp to moc the test object in foo_test.cpp. This is 'correct' compared to what qmake does. Yes. * KDE does eg, include kjob_p.moc in kjob.cpp to cause kjob_p.h to be moc'd. The RestoreAutmocKDECompatibility branch introduces a commit which makes this not work because the source file has a different basename. Yes. I did not expect somebody would be doing this. I don't want to support this for Qt5. I can add a fix with a warning for Qt4. This is not uncommon in both KDE and in Qt itself, or any other project where it makes sense to put a QObject-inherited class in the _p.h as an internally used class. See for example, qplaintextedit.cpp: #include moc_qplaintextedit.cpp #include moc_qplaintextedit_p.cpp This should be supported by the automoc feature. I have also seen places (I think in QtDeclarative) where a foo.cpp file included the file moc_bar.cpp, though that is very uncommon. The logic that I would use would be something like: find #include moc_(.*).cpp - generate moc for \\1.h find #include (.*).moc - generate moc for \\1.cpp Was there a reason for preventing this? I think we need to have a list of exactly what cases should be supported, This is the current documentation of automoc in cmake. I was hoping it would be relatively clear: If an #include statement like #include \moc_foo.cpp\ is found, the Q_OBJECT class declaration is expected in the header, and moc is run on the header file. If an #include statement like #include \foo.moc\ is found, then a Q_OBJECT is expected in the current source file and moc is run on the file itself. Additionally, all header files are parsed for Q_OBJECT macros, and if found, moc is also executed on those files. The resulting moc files, which are not included as shown above in any of the source files are included in a generatedtargetname_automoc.cpp file, which is compiled as part of the target. This should be compatible to qmake, and this is what I'd like to support for Qt5. Nearly. As you can see, there are quite some differences compared to the qmake behavior. and fix KDE to do the right thing. I think in many cases, fixing KDE will just be removing the explicit include foo.moc which is intended to run moc on foo.h, and let the automatic moc'ing do the work. If any other 'KDE compatilbility' features are in cmQtAutomoc which differ from qmake behavior, I really think it should be behind an option which is off by default, which KDE turns on, and then actively ports away
Re: [cmake-developers] cmake automoc breaks kde
On Tuesday 22 November 2011, Stephen Kelly wrote: On 11/22/2011 06:20 PM, Alexander Neundorf wrote: Using Qt5 or Qt4 ? Qt4. There seems to be several problems: * KDE does include foo.moc if it wants the header file to be moc'd. This is 'incorrect' compared to what qmake expects, which would be a moc_foo.cpp include. Yes. * Some places in KDE use include moc_foo.cpp 'correctly', but there are only about 10 occurrences. The current automoc tool seems to handle that, as does cmake 2.8.6 apparently. I thought about this. There are 4 constellations, and only one constellation where things can break: * foo.cpp includes neither foo.moc nor moc_foo.cpp. No problem. Sort of. There are cases where the moc file must be included in the cpp file (see below). But this removal of includes is what we should aim for in KDE. I think if the options are: 1) Introduce odd hacky KDE specific workarounds to CMake 2) Remove the problematic includes from KDE files in the frameworks branch I will side with option 2). CMAKE_AUTOMOC is not used in KDE4. The feature is only really relevant to non KDE Qt4 users. Let's just 'fix the bug' in the frameworks iteration of kdelibs. * if foo.cpp includes both foo.moc and moc_foo.cpp, then both foo.h and foo.cpp will be moc'ed, and it doesn't matter which one is for which. No problem. It seems there is a test missing for this case. Yes. * if foo.cpp includes only foo.moc, then foo.cpp will be moc'ed. This may be unnecessary, but shouldn't create problems. If foo.h also needs to be moc'ed, it will be, and the resulting moc_foo.cpp will be included in the target_automoc.cpp file. So it should also work. This is Tests/QtAutomoc/codeeditor.cpp Sort of. There are cases where the moc file must be included in the cpp file, because it needs definitions from the .h file. (eg, use of the Q_PRIVATE_SLOT macro). I don't know that one. Are there docs somewhere ? I have also seen a I think Q_GADGET macro mentioned somewhere, but also didn't find docs. If they exist and require special handling, adding this special handling is fine IMO. If a KDE developer included foo.moc expecting that to be the result of moc'ing the .h file, the build will fail. In this case, foo.cpp needs to be fixed to include moc_foo.cpp instead. I don't think CMake should introduce a hack for this. * problematic case: if foo.cpp includes only moc_foo.cpp, then cmake will check whether foo.cpp contains Q_OBJECT. If it does, it will: ** fail with Qt5, stating that foo.cpp contains Q_OBJECT but does not include foo.moc, so it can't work I think this is fine. ** warn with Qt4 that it will run moc on foo.cpp instead of foo.h to generate moc_foo.cpp This is Tests/QtAutomoc/blub.cpp * KDE does include foo_test.moc in foo_test.cpp to moc the test object in foo_test.cpp. This is 'correct' compared to what qmake does. Yes. * KDE does eg, include kjob_p.moc in kjob.cpp to cause kjob_p.h to be moc'd. The RestoreAutmocKDECompatibility branch introduces a commit which makes this not work because the source file has a different basename. Yes. I did not expect somebody would be doing this. I don't want to support this for Qt5. I can add a fix with a warning for Qt4. This is not uncommon in both KDE and in Qt itself, or any other project where it makes sense to put a QObject-inherited class in the _p.h as an internally used class. See for example, qplaintextedit.cpp: #include moc_qplaintextedit.cpp #include moc_qplaintextedit_p.cpp This should be supported by the automoc feature. Yes, it should work. I'm adding a test. I have also seen places (I think in QtDeclarative) where a foo.cpp file included the file moc_bar.cpp, though that is very uncommon. The logic that I would use would be something like: find #include moc_(.*).cpp - generate moc for \\1.h This should work right now. I thought there is a test for this. Checking. find #include (.*).moc - generate moc for \\1.cpp Was there a reason for preventing this? We can do that, but how can that work ? I mean, this will generate code for a class which is declated in a different source file, so it is unknown in the including file, no ? I think we need to have a list of exactly what cases should be supported, This is the current documentation of automoc in cmake. I was hoping it would be relatively clear: If an #include statement like #include \moc_foo.cpp\ is found, the Q_OBJECT class declaration is expected in the header, and moc is run on the header file. If an #include statement like #include \foo.moc\ is found, then a Q_OBJECT is expected in the current source file and moc is run on the file itself. Additionally, all header files are parsed for Q_OBJECT macros, and if found, moc is also executed on those files. The resulting moc files, which are not included as shown above in any of the
Re: [cmake-developers] Multiple dependent install(EXPORT) sets
Alexander Neundorf wrote: On Tuesday 22 November 2011, Brad King wrote: On 11/22/2011 10:03 AM, Stephen Kelly wrote: Brad King wrote: We will have to require that the install(EXPORT) commands be invoked in dependency order (ex. A before B). That way when the command installing ExportB is writing library B's dependency on A, it can transform the name using the options that had been given to the install command for ExportA, such as its NAMESPACE. This is required because ExportB will create an imported target for library B and that imported target will list its dependency on an imported target for library A. What is that imported target called? Where is it defined? Only ExportA knows, and then only after its install(EXPORT) has been called. Yes. Where/why is it actually necessary to split libraries installed from one package into multiple Config.cmake files ? This is now to install separate libraries from a big kdelibs, right ? Maybe we (KDE) simply shouldn't do this, and just start with it once the big modules are broken into separate parts. Maybe. Should nobody install multiple 'modular pieces' from one top level CMakeLists.txt? It's sort of superbuild without superbuild, but with the advantage that the sources are in the source directory. Then each of the smaller parts can install a Config.cmake file for all its libraries. If e.g. libkgui depends on libkcore, currently those two targets would exist in one project, but installed as two export sets. Once they are separated into two projects, then libkgui depends already on the imported target KDE::kcore (or how it is named), and referencing this in its Targets.cmake file works fine. Does a target know its imported target name or is it really just the export mechanism? Would it be possible for the export mechanism to inform the targets of their imported target name and location so that that information can be retrieved by dependents? Consider this: add_library(bar) add_library(foo) target_link_libraries(foo bar) install(TARGETS bar EXPORT barTargets ...) install(TARGETS foo EXPORT fooTargets ...) install(EXPORTS barTargets NAMESPACE myNS) # sets a property on bar that its # imported name is myNS::bar install(EXPORTS fooTargets NAMESPACE otherNS) # Maps from the LINK_LIBRARIES # information 'bar' to # 'myNS::bar' to populate the # dependency information This also removes the need for explicit dependencies between install(EXPORTS) invocations, which is already implicitly specified by the (public) link interface of targets build in the same build system. We do this already with Qt4. You mean in FindQt4.cmake? I'm not sure it's the same situation. Furthermore, the targets file generated for ExportB will need to include() the file generated for ExportA using the DESTINATION given to the latter to make its targets available. And its FILE presumably, but why? This ties in to the question of whether find_package(B) should find the dependencies of B: We could leave this part out and leave it up to the Config.cmake file author to ensure ExportA's targets file is loaded when ExportB's targets file is loaded. Why the Config file author? Why not the consumer of the config files? You mean that the author of BConfig.cmake should ensure that ExportA's targets file is loaded? How would it do that without a find_package(A)? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On 11/22/2011 07:10 PM, Alexander Neundorf wrote: find #include (.*).moc - generate moc for \\1.cpp Was there a reason for preventing this? We can do that, but how can that work ? I mean, this will generate code for a class which is declated in a different source file, so it is unknown in the including file, no ? You're right sorry, I was just cut+paste+modifying. If #include (.*).moc CMAKE_MATCH_1 MATCHES basename, then moc self I guess. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Tuesday 22 November 2011, Alexander Neundorf wrote: On Tuesday 22 November 2011, Stephen Kelly wrote: ... This is not uncommon in both KDE and in Qt itself, or any other project where it makes sense to put a QObject-inherited class in the _p.h as an internally used class. See for example, qplaintextedit.cpp: #include moc_qplaintextedit.cpp #include moc_qplaintextedit_p.cpp This should be supported by the automoc feature. Yes, it should work. I'm adding a test. Test added, works. What is not working right now is including someotherfile.moc. I could add special handling for including thisfile_p.moc (as opposed to moc_thisfile_p.cpp, which works). I have also seen places (I think in QtDeclarative) where a foo.cpp file included the file moc_bar.cpp, though that is very uncommon. The logic that I would use would be something like: find #include moc_(.*).cpp - generate moc for \\1.h This should work right now. I thought there is a test for this. Checking. Test added, works. Can you please update from this branch and see what testcases are missing in QtAutomoc/Tests/ ? Thanks Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On 11/22/2011 07:37 PM, David Faure wrote:
On Tuesday 22 November 2011 14:33:25 Stephen Kelly wrote:
I think in many cases,
fixing KDE will just be removing the explicit include foo.moc which is
intended to run moc on foo.h, and let the automatic moc'ing do the work.
No, to include moc_foo.cpp instead, if that's what cmake automoc would
generate.
If you don't include any moc, then the moc is compiled separately, which leads
to slower compilation.
Are you sure? I think all moc files of a target which are not included
elsewhere are included in a _automoc.cpp file, which is then built as
the automoc target. See ${kdeui_BUILD_DIR}/kdeui_automoc.cpp for example.
There should be no slowdown AFAICT.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] slow regex implementation in RegularExpression
On 2011-11-17, at 3:59 PM, Brad King wrote:
On 11/17/2011 3:19 PM, Alexandru Ciobanu wrote:
I was able to make CMake use TRE, by changing the
RegularExpression.{cxx,hxx.in} files.
Those are down in Source/kwsys which is a directory shared by
projects other than just CMake. We cannot touch the files there.
Instead you will need to re-factor things to go through a wrapper.
The first stage will just wrap up the KWSys regular expression API.
The second stage will replace the implementation with TRE.
- Does anyone see a problem if we add TRE in CMake the same
way as ZLIB, CURL, etc? (i.e. in ./Utilities/)
That should be fine.
-Brad
Hi,
As Brad King suggested, instead of changing the files in Source/kwsys/, I
created a wrapper class and made all the calls go through it.
I also added the TRE library to Utilities/cmtre, and added CMAKE_USE_SYSTEM_TRE.
I added the patch to the bug tracker:
http://public.kitware.com/Bug/view.php?id=12381
Needless to say, the patch fixes the performance problem.
To keep things simple I omitted several things:
- TRE library bootstrapping (so now the Bootstrap test will fail)
- the suggested policy to enable/disable approximate matching in TRE
- proper checks when building TRE with CMake as done in its ./configure.ac
Before I spend more time on that I would like to get some feedback, and namely:
- Is the approach correct?
- What next?
sincerely,
Alex Ciobanu--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Multiple dependent install(EXPORT) sets
On Tuesday 22 November 2011, Stephen Kelly wrote: Alexander Neundorf wrote: On Tuesday 22 November 2011, Brad King wrote: On 11/22/2011 10:03 AM, Stephen Kelly wrote: Brad King wrote: We will have to require that the install(EXPORT) commands be invoked in dependency order (ex. A before B). That way when the command installing ExportB is writing library B's dependency on A, it can transform the name using the options that had been given to the install command for ExportA, such as its NAMESPACE. This is required because ExportB will create an imported target for library B and that imported target will list its dependency on an imported target for library A. What is that imported target called? Where is it defined? Only ExportA knows, and then only after its install(EXPORT) has been called. Yes. Where/why is it actually necessary to split libraries installed from one package into multiple Config.cmake files ? This is now to install separate libraries from a big kdelibs, right ? Maybe we (KDE) simply shouldn't do this, and just start with it once the big modules are broken into separate parts. Maybe. Should nobody install multiple 'modular pieces' from one top level CMakeLists.txt? It's sort of superbuild without superbuild, but with the advantage that the sources are in the source directory. Yes, maybe, but this was not initially the goal, so that doesn't work right now. The motivation for exporting multiple sets of targets from one project was (at least among others) to be able to export libraries and executables separately. This way when crosscompiling, the crosscompiled project can import the executable targets from a native build, and do e.g. get_target_property(LOCATION ) on the imported executable target the same way it can do that in the native build where it has really built the executable. Also executable targets are recognized as commands in add_custom_command() and add_custom_executable(), so you can simply use the target name there and don't have to care whether it is an imported executable target from a native build or whether you are natively building. For that purpose splitting the libraries into multiple dependend sets was not necessary (which doesn't mean it would be a bad thing). Then each of the smaller parts can install a Config.cmake file for all its libraries. If e.g. libkgui depends on libkcore, currently those two targets would exist in one project, but installed as two export sets. Once they are separated into two projects, then libkgui depends already on the imported target KDE::kcore (or how it is named), and referencing this in its Targets.cmake file works fine. Does a target know its imported target name or is it really just the export mechanism? It's only in the export sets. You can also put a target into multiple export sets, with different namespaces etc. if you want to. With that, one exported target doesn't know which of the potentially multiple names of the exported target it depends on it should use. Would it be possible for the export mechanism to inform the targets of their imported target name and location so that that information can be retrieved by dependents? Consider this: add_library(bar) add_library(foo) target_link_libraries(foo bar) install(TARGETS bar EXPORT barTargets ...) install(TARGETS foo EXPORT fooTargets ...) install(EXPORTS barTargets NAMESPACE myNS) # sets a property on bar that its # imported name is myNS::bar install(EXPORTS barTargets NAMESPACE myNS2) #didn't test but I think it works install(EXPORTS fooTargets NAMESPACE otherNS) # Maps from the LINK_LIBRARIES # information 'bar' to # 'myNS::bar' to populate the # dependency information # or myNS2 ? ... This also removes the need for explicit dependencies between install(EXPORTS) invocations, which is already implicitly specified by the (public) link interface of targets build in the same build system. We do this already with Qt4. You mean in FindQt4.cmake? I'm not sure it's the same situation. I was talking about the following: FindQt4.cmake creates imported targets. In kdelibs we link against them. The names of the imported targets from Qt4 appear again in the Targets.cmake file for kdelibs: # Import target KDE4__kdecore for configuration RelWithDebInfo ... SET_TARGET_PROPERTIES(KDE4__kdecore PROPERTIES IMPORTED_LINK_INTERFACE_LIBRARIES_RELWITHDEBINFO Qt4::QtDBus;Qt4::QtCore;- lpthread IMPORTED_LOCATION_RELWITHDEBINFO /home/alex/Dashboards/installs/2.8.1/kdelibs/lib/libkdecore.so.5.5.0 IMPORTED_SONAME_RELWITHDEBINFO libkdecore.so.5 ) In FindKDE4Internal.cmake we do find_package(Qt4), which creates the imported
Re: [cmake-developers] cmake automoc breaks kde
On Tuesday 22 November 2011, Stephen Kelly wrote: On 11/10/2011 10:16 PM, Alexander Neundorf wrote: ... Please give the RestoreAutmocKDECompatibility branch on cmake stage a try. It should work again, but print a warning if a file includes a moc_foo.cpp, but no foo.moc, and contains a Q_OBJECT macro. For Qt5 I'd prefer to not support that anymore. I.e. moc_foo.cpp - header, foo.moc - source file. Alex I tried that branch. It doesn't build the frameworks branch for me. I found the mistake ! When I wrote that mail two weeks ago it was the RestoreAutmocKDECompatibility branch. This got merged into master in the meantime. Once your Qt5 branch was merged, I created a new branch named AutomocIncludedDotMocFileHandling. This is the branch I'm talking about. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 3/3] Add the Ninja generator
On Mon, Nov 14, 2011 at 08:18:16AM +0100, Rolf Eike Beer wrote:
diff --git a/Modules/Compiler/GNU.cmake b/Modules/Compiler/GNU.cmake
index 8d6f5df..bdcaf9d 100644
--- a/Modules/Compiler/GNU.cmake
+++ b/Modules/Compiler/GNU.cmake
@@ -24,6 +24,15 @@ macro(__compiler_gnu lang)
set(CMAKE_SHARED_LIBRARY_${lang}_FLAGS -fPIC)
set(CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS -shared)
+ # Older versions of gcc ( 4.5) contain a bug causing them to report a
missing + # header file as a warning if depfiles are enabled, causing
check_header_file + # tests to always succeed. Work around this by
disabling dependency tracking + # in try_compile mode.
+ GET_PROPERTY(_IN_TC GLOBAL PROPERTY IN_TRY_COMPILE)
+ if(NOT _IN_TC OR CMAKE_FORCE_DEPFILES)
+set(CMAKE_DEPFILE_FLAGS_${lang} -MMD -MF DEPFILE)
+ endif()
+
# Initial configuration flags.
set(CMAKE_${lang}_FLAGS_INIT )
set(CMAKE_${lang}_FLAGS_DEBUG_INIT -g)
This may only affect Ninja, but it looks like a general bug. Shouldn't this
be
it's own commit then?
The Ninja generator is the only user of CMAKE_DEPFILE_FLAGS_${lang}
variables. I will add this in its own commit to make it clear that
these variables can also be used by other generators.
Thanks,
--
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 0/3] The CMake Ninja generator.
On Tuesday 22 November 2011, Peter Collingbourne wrote: On Tue, Nov 15, 2011 at 06:54:01PM +0100, Nicolas Desprès wrote: On Tue, Nov 15, 2011 at 5:29 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 11/11/2011 9:36 PM, Peter Collingbourne wrote: Note that this generator is *nix only (it relies on POSIX shell functionality), and will only be built on *nix platforms. I am not interested in Windows support, but I understand that others have expressed an interest in adding support. How much of the POSIX shell stuff can be done with cmake -E stuff? It would be good to use as little POSIX stuff as possible as someday when someone does the inevitable windows port it is easier... Too much in my opinion. Specially the operator of the shell. Using cmake -E is the first step. I am planning to suggest an evolution of Ninja to fix this issue. Actually, it is the main issue which stop me while writing the beginning of this generator. Other than we also have: rm -f $file -- used to delete static library archives before rebuilding cmake -E remove -f $file : -- used as a no-op command maybe cmake -E echo Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
Alexander Neundorf wrote: Test added, works. What is not working right now is including someotherfile.moc. I could add special handling for including thisfile_p.moc (as opposed to moc_thisfile_p.cpp, which works). Yes, this is the issue that makes the build break in the frameworks branch. It is mostly all breakage due to the thisfile_p.moc issue and expecting thisfile.moc to run moc on the .h file. All can be considered incorrect in frameworks IMO and I can fix them there. I'll just have to make sure that they also work with cmake 2.8.6. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On 11/22/2011 08:43 PM, Alexander Neundorf wrote: On Tuesday 22 November 2011, Stephen Kelly wrote: On 11/10/2011 10:16 PM, Alexander Neundorf wrote: ... Please give the RestoreAutmocKDECompatibility branch on cmake stage a try. It should work again, but print a warning if a file includes a moc_foo.cpp, but no foo.moc, and contains a Q_OBJECT macro. For Qt5 I'd prefer to not support that anymore. I.e. moc_foo.cpp - header, foo.moc - source file. Alex I tried that branch. It doesn't build the frameworks branch for me. I found the mistake ! When I wrote that mail two weeks ago it was the RestoreAutmocKDECompatibility branch. This got merged into master in the meantime. Once your Qt5 branch was merged, I created a new branch named AutomocIncludedDotMocFileHandling. This is the branch I'm talking about. Alex Actually I've been using that branch all along. Now when I try to build the frameworks branch using the cmake next branch, I get: AUTOMOC: error: /home/stephen/dev/src/kf5/tier1/libkcoreaddons/src/io/kdirwatch.cpp: The file includes the moc file kdirwatch_p.moc, which seems to be the moc file from a different source file. This is not supported. Include kdirwatch.moc to run moc on this source file. I then get a good deal of /home/stephen/dev/src/kf5/tier1/libkauth/HelperProxy.cpp:0: Note: No relevant classes found. No output generated. Generating FakeHelperProxy.moc /home/stephen/dev/src/kf5/tier1/itemmodels/src/kcheckableproxymodel.cpp:0: Note: No relevant classes found. No output generated. Generating moc_kdescendantsproxymodel.cpp /home/stephen/dev/src/kf5/tier1/libkauth/backends/fakehelper/FakeHelperProxy.cpp:0: Note: No relevant classes found. No output generated. The warnings are good because they indicate doing it the wrong way. As I noted in the other mail, I'll fix these issues in the frameworks branch. Do you want testcases for them in cmake to workaround it there? -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Tuesday 22 November 2011, Stephen Kelly wrote: On 11/22/2011 08:43 PM, Alexander Neundorf wrote: On Tuesday 22 November 2011, Stephen Kelly wrote: On 11/10/2011 10:16 PM, Alexander Neundorf wrote: ... Please give the RestoreAutmocKDECompatibility branch on cmake stage a try. It should work again, but print a warning if a file includes a moc_foo.cpp, but no foo.moc, and contains a Q_OBJECT macro. For Qt5 I'd prefer to not support that anymore. I.e. moc_foo.cpp - header, foo.moc - source file. Alex I tried that branch. It doesn't build the frameworks branch for me. I found the mistake ! When I wrote that mail two weeks ago it was the RestoreAutmocKDECompatibility branch. This got merged into master in the meantime. Once your Qt5 branch was merged, I created a new branch named AutomocIncludedDotMocFileHandling. This is the branch I'm talking about. Alex Actually I've been using that branch all along. I noticed I slightly got confused by all the branches, sorry. Now when I try to build the frameworks branch using the cmake next branch, I get: AUTOMOC: error: /home/stephen/dev/src/kf5/tier1/libkcoreaddons/src/io/kdirwatch.cpp: The file includes the moc file kdirwatch_p.moc, which seems to be the moc file from a different source file. This is not supported. Include kdirwatch.moc to run moc on this source file. I added special handling now for the case that basename_p.moc is included with Qt4. I then get a good deal of /home/stephen/dev/src/kf5/tier1/libkauth/HelperProxy.cpp:0: Note: No relevant classes found. No output generated. Generating FakeHelperProxy.moc /home/stephen/dev/src/kf5/tier1/itemmodels/src/kcheckableproxymodel.cpp:0: Note: No relevant classes found. No output generated. Generating moc_kdescendantsproxymodel.cpp /home/stephen/dev/src/kf5/tier1/libkauth/backends/fakehelper/FakeHelperProx y.cpp:0: Note: No relevant classes found. No output generated. The warnings are good because they indicate doing it the wrong way. As I noted in the other mail, I'll fix these issues in the frameworks branch. Do you want testcases for them in cmake to workaround it there? Please have a look at the current AutomocIncludedDotMocFileHandling branch and see if there are still things missing. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] slow regex implementation in RegularExpression
On 11/22/2011 1:50 PM, Alexandru Ciobanu wrote: As Brad King suggested, instead of changing the files in Source/kwsys/, I created a wrapper class and made all the calls go through it. Thanks. I also added the TRE library to Utilities/cmtre, and added CMAKE_USE_SYSTEM_TRE. I added the patch to the bug tracker: http://public.kitware.com/Bug/view.php?id=12381 Please add a note there indicating the CMake version (git commit sha1) on which the patch was based. Otherwise I cannot apply it cleanly. Needless to say, the patch fixes the performance problem. Great! To keep things simple I omitted several things: - TRE library bootstrapping (so now the Bootstrap test will fail) The KWSys implementation will not be going away, so we can fall back to that one during bootstrapping. - the suggested policy to enable/disable approximate matching in TRE Please read up on policies to make sure you understand them: http://www.cmake.org/Wiki/CMake/Policies http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:cmake_policy http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Policies We will need a policy to know how to treat a regex containing one of the characters that behaves differently in TRE. The OLD behavior of the policy will escape them to get the old matching behavior. The NEW behavior of the policy will use the new matching features. We also need to identify the contexts that offer regex matching but have no way to set the policy. For those we need to decide if we can simply use the new behavior outright or provide another way to switch it. It is tempting to always require explicit requests for new TRE behavior, such as using TRE instead of REGEX in keyword locations, but one advantage of using a policy is that over time the old behavior will disappear completely from usage. - proper checks when building TRE with CMake as done in its ./configure.ac IOW, porting TRE to build properly with CMake, right? - Is the approach correct? Yes. I will review the patch in more detail next week and after I know where to apply it. - What next? We need to establish a transition plan, which mostly consists of the above policy discussion. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On 11/22/2011 10:03 PM, Alexander Neundorf wrote: Now when I try to build the frameworks branch using the cmake next branch, I get: AUTOMOC: error: /home/stephen/dev/src/kf5/tier1/libkcoreaddons/src/io/kdirwatch.cpp: The file includes the moc file kdirwatch_p.moc, which seems to be the moc file from a different source file. This is not supported. Include kdirwatch.moc to run moc on this source file. I added special handling now for the case that basename_p.moc is included with Qt4. Your new commits work with the parts of the frameworks branch affected by this, yes. However, there are still many places where the foo.moc file is expected to be the result of moc'ing the header, which causes errors like this: In file included from /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/kdbus_automoc.cpp:2:0: /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.cpp: In static member function 'static void KDBusInterProcessLock::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)': /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/moc_kdbusinterprocesslock.cpp:55:22: error: invalid use of incomplete type 'struct KDBusInterProcessLockPrivate' /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/../../../../../src/kf5/tier1/libkdbus/kdbusinterprocesslock.h:30:7: error: forward declaration of 'struct KDBusInterProcessLockPrivate' Fixed by changing the include from foo.moc to moc_foo.cpp of course. This is due to the use of Q_PRIVATE_SLOT. I've just added a testcase to the branch. I then get a good deal of /home/stephen/dev/src/kf5/tier1/libkauth/HelperProxy.cpp:0: Note: No relevant classes found. No output generated. Generating FakeHelperProxy.moc /home/stephen/dev/src/kf5/tier1/itemmodels/src/kcheckableproxymodel.cpp:0: Note: No relevant classes found. No output generated. Generating moc_kdescendantsproxymodel.cpp /home/stephen/dev/src/kf5/tier1/libkauth/backends/fakehelper/FakeHelperProx y.cpp:0: Note: No relevant classes found. No output generated. The warnings are good because they indicate doing it the wrong way. As I noted in the other mail, I'll fix these issues in the frameworks branch. Do you want testcases for them in cmake to workaround it there? Please have a look at the current AutomocIncludedDotMocFileHandling branch and see if there are still things missing. I'll try building frameworks and see what still fails. I do get an error in solid which again is due to including the foo.moc file and expecting that to be the result of moc'ing the header. It only works currently due to a quirk in the include order in that file, so I don't think it's worth working around or testing. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] slow regex implementation in RegularExpression
I also added the TRE library to Utilities/cmtre, and added CMAKE_USE_SYSTEM_TRE. I added the patch to the bug tracker: http://public.kitware.com/Bug/view.php?id=12381 Please add a note there indicating the CMake version (git commit sha1) on which the patch was based. Otherwise I cannot apply it cleanly. The commit that the patch is based on is: 5675ec5e493e01e10d9ad8d8b60eac62033f31c2 I added a note to the bug tracker. To keep things simple I omitted several things: - TRE library bootstrapping (so now the Bootstrap test will fail) The KWSys implementation will not be going away, so we can fall back to that one during bootstrapping. This is a good idea. - proper checks when building TRE with CMake as done in its ./configure.ac IOW, porting TRE to build properly with CMake, right? Yes, there are some checks, find headers, find types, etc. But all these operations have equivalents in CMake. So it should be straightforward. sincerely, Alex Ciobanu-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] VC2010 Express crashing
On 21.11.11 17:37:14, Robert Dailey wrote: On Mon, Nov 21, 2011 at 5:32 PM, John Drescher dresche...@gmail.com wrote: Yes it is 100% reproducible. I don't know if telling someone to send reports to Microsoft and have them fix the problem is the most reasonable solution. Isn't it a Microsoft bug? I mean even if the sln file was somehow wrong Visual Studio should not crash when using it. I agree but if there is a workaround that can be used, I prefer that in the meantime since obviously whatever is causing the problem probably won't be fixed in the next 6 months, if at all. For example, if CMake is generating something that doesn't mix well with VC 2010 Express, it would be nice to know what that is so maybe I can work around the issue. I can't think of any way to debug this problem though. You could try disabling some of your 120 projects if they don't have too many interdependencies and see wether the resulting solution file still crashes VS. This would maybe allow you to find out which cmake commands lead to the solution that crashes VS. Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ccmake was not created
On 11/22/2011 09:28 AM, Mikhail Artemiev wrote: I don't see a BUILD_CursesDialog entry in my CMakeCache.txt file.But a CURSES_NCURSES_LIBRARY entry exists, and it point to /usr/lib/libncurses.so (which exists too).When I try to add a string BUILD_CursesDialog:BOOL=ON intoCMakeCache.txt by hand and then remake the project,CMakeCache.txt reloads, deleting my string.Mikhail In your bootstrap log, do you see something like the following? Curses libraries were not found. Curses GUI for CMake will not be built. Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ccmake was not created
In your bootstrap log, do you see something like the following? Curses libraries were not found. Curses GUI for CMake will not be built. Yes. But I don't understand. The curses library was installed. My LD_LIBRARY_PATH is $echo $LD_LIBRARY_PATH /usr/lib What's wrong? Mikhail -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ccmake was not created
On 11/22/2011 10:58 AM, Mikhail Artemiev wrote: In your bootstrap log, do you see something like the following? Curses libraries were not found. Curses GUI for CMake will not be built. Yes. But I don't understand. The curses library was installed. My LD_LIBRARY_PATH is $echo $LD_LIBRARY_PATH /usr/lib What's wrong? Mikhail Try removing the QUIET option from the FIND_PACKAGE(Curses QUIET) call in the CMakeLists.txt file and then run bootstrap again. This should tell you more what's going on. Other things to check for in the cache: CURSES_LIBRARY CURSES_INCLUDE_PATH Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Components in DMG but outside OSX Application Bundle
Hi, I'm trying to create an OSX Application Bundle but like to include the documentation in a separate directory outside the app bundle but still in the dmg. Currently cpack installs all components into the app (CPACK_BUNDLE_COMPONENT_INSTALL ignored). Now for this to work I guess I would have to 1) enable component based install for the bundle generator 2) make sure only the runtime component is installed into the app 3) inject a cmake install script that installs the documentation component in a separate directory along with the app (before the dmg is created). I don't know how to solve (1) but from reading the documentation and looking at previous posts in this list I guess (3) can be achieved with CPACK_INSTALL_COMMANDS or CPACK_INSTALL_SCRIPT. Thanks, Florian -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Clen-up pre-built software
Hi Community, In the large project we a having periodic taks which build a couple of projects and store the result of the build in one specific place. Once it's build the rest of the team can use this artifacts becouse those are exported by using of export(TARGETS ...) Since the others refer only to the targets I would like to clean-up the common builds from optional artifacts in order to save some disk space. I guess the objects could be removed. The problem is that make clean will clean also executables and libraries, so it's not an option for me. 1) Is there any way to get all objects files as a list, so I can remove them in the loop ? 2) Is there any other way to cope with this clean-up ? Looking for hints. Best regards, T Majchrowski. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] global variable vs cache variable
Hi Community, I could not found any other possibilites to set some global variable than using a cache variable. Even if this is not nice sometimes you need to have a global variable. So I would like to ask about advice in this area: 1) Is this the real use case for cache, so to use it as a global variables container. In my understanding this is something that is intended to use if you would like to save some values between separate calls of the cmake. 2) Is there any performance issue with using of cache, I/O, etc? What is better way use PARENT_SCOPE in the loop to forward the variable to the upper level scope or just CMakeCache. Looking for advise, Best regards, T. Majchrowski -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Clen-up pre-built software
Am 22.11.2011 11:42, schrieb t m: Hi Community, In the large project we a having periodic taks which build a couple of projects and store the result of the build in one specific place. Once it's build the rest of the team can use this artifacts becouse those are exported by using of export(TARGETS ...) Since the others refer only to the targets I would like to clean-up the common builds from optional artifacts in order to save some disk space. I guess the objects could be removed. The problem is that make clean will clean also executables and libraries, so it's not an option for me. 1) Is there any way to get all objects files as a list, so I can remove them in the loop ? 2) Is there any other way to cope with this clean-up ? Looking for hints. Make different trees for build and export (aka installation to a specific location to be used by others). Then you can easily delete the build tree. HS -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] global variable vs cache variable
On 11/22/2011 11:51 AM, t m wrote: Hi Community, I could not found any other possibilites to set some global variable than using a cache variable. Even if this is not nice sometimes you need to have a global variable. So I would like to ask about advice in this area: 1) Is this the real use case for cache, so to use it as a global variables container. In my understanding this is something that is intended to use if you would like to save some values between separate calls of the cmake. 2) Is there any performance issue with using of cache, I/O, etc? What is better way use PARENT_SCOPE in the loop to forward the variable to the upper level scope or just CMakeCache. Looking for advise, Best regards, T. Majchrowski Use the cache only if the values need to be persistent. Otherwise I recommend using a GLOBAL property. See set_property() and get_property(). Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Xcode: Nested Xcode Projects
Hi, I am currently generating sub projects with cmake using the add_subdirectory command together with the Xcode generator. It works, but the top level Xcode project includes the sources and targets of all the sub projects. Is it possible to make it reference the actual Xcode sub projects instead(to get closer to a normal Xcode workflow)? If it's not possible with current CMake it would certainly be a very neat addition! Thanks -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode: Nested Xcode Projects
Hi, CMake doesn't support Xcode workspaces like it does Visual Studio solutions. But you can still define multiple PROJECT()'s that will all be visible and buildable (via the scheme selector) in the IDE. In our setup, we have a bunch of apps and a library, in the top level CMakeLists.txt we do... PROJECT(Suite) ADD_SUBDIRECTORY(Lib) ADD_SUBDIRECTORY(App0) ... ADD_SUBDIRECTORY(Appn) And every CMakeLists.txt in the leaves of the source tree contains exactly one PROJECT() call: Lib: PROJECT(Lib) ... ADD_LIBRARY(Lib ...) App0: PROJECT(App0) ... ADD_EXECUTABLE(App0 ...) ... App1: PROJECT(Appn) ... ADD_EXECUTABLE(Appn ...) But yes... workspaces would be great. Daniel On Nov 22, 2011, at 1:28 PM, Matthias Dörfelt wrote: Hi, I am currently generating sub projects with cmake using the add_subdirectory command together with the Xcode generator. It works, but the top level Xcode project includes the sources and targets of all the sub projects. Is it possible to make it reference the actual Xcode sub projects instead(to get closer to a normal Xcode workflow)? If it's not possible with current CMake it would certainly be a very neat addition! Thanks -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VC2010 Express crashing
I'm sorry if that sounded flippant... but I'm 100% serious. I used to work there, and they take the crash reports very seriously, and they actually do get the majority of them fixed eventually. But if you don't send them in, then they don't know about them. Also: I've simply never heard this complaint before, so I'd be surprised if it was CMake's fault. Having said all of this, though, please do send us steps so that we can reproduce the problem, or possibly, figure out if there's something wrong with the generated files that can be changed. If we can incorporate a work-around into CMake, then we are happy to do so. We have work-arounds in there for far less serious bugs than complete/100% reproducible crashing bugs... Thanks, David On Mon, Nov 21, 2011 at 6:24 PM, Robert Dailey rcdai...@gmail.com wrote: Yes it is 100% reproducible. I don't know if telling someone to send reports to Microsoft and have them fix the problem is the most reasonable solution. - Robert Dailey On Mon, Nov 21, 2011 at 5:18 PM, David Cole david.c...@kitware.com wrote: Submit/send your crash reports to Microsoft so they can fix it... I haven't heard of a problem like this. Is it 100% reproducible? (i.e. does it happen every time you do this?) On Mon, Nov 21, 2011 at 4:30 PM, Robert Dailey rcdai...@gmail.com wrote: Unfortunately I don't have a whole lot of details to share here, so I'm hoping someone can tell me what steps I can take to debug this issue. I generated about 120 projects in a VC2010 Express solution and opened it. Everything opened fine. I pick any project in the solution, right-click it, and select Build... Visual Studio crashes. I'm running Windows 7 x64 Ultimate and CMake 2.8.6. If I generate for VS7.1 and VS9 using the same scripts, visual studio does not crash in those versions and builds just fine. Note however that I am not using the express versions in those cases. - Robert Dailey -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] global variable vs cache variable
Use the cache only if the values need to be persistent. Otherwise I
recommend using a GLOBAL property. See set_property() and get_property().
Michael
Thank you Michael. Looks good. So let me summarize. The workflow
should looks like follow:
1. Top Level CMakeLists.txt:
add_subdirectory( foo )
2. Level 2 foo/CMakeLists.txt
set_property ( GLOBAL P_A PROPERTY some value)
3. Level 1 CMakeLists.txt
get_property ( VAR_A GLOBAL PROPERY P_A)
message (STATUS VAR_A=${VAR_A})
is that's right?
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VC2010 Express crashing
No problem. I'll send a crash report to MS and see what I can figure out. I assume I need to report the crash on the MSDN forums? Never reported a MS bug before so not sure. Thanks for the help everyone. - Robert Dailey On Tue, Nov 22, 2011 at 6:52 AM, David Cole david.c...@kitware.com wrote: I'm sorry if that sounded flippant... but I'm 100% serious. I used to work there, and they take the crash reports very seriously, and they actually do get the majority of them fixed eventually. But if you don't send them in, then they don't know about them. Also: I've simply never heard this complaint before, so I'd be surprised if it was CMake's fault. Having said all of this, though, please do send us steps so that we can reproduce the problem, or possibly, figure out if there's something wrong with the generated files that can be changed. If we can incorporate a work-around into CMake, then we are happy to do so. We have work-arounds in there for far less serious bugs than complete/100% reproducible crashing bugs... Thanks, David On Mon, Nov 21, 2011 at 6:24 PM, Robert Dailey rcdai...@gmail.com wrote: Yes it is 100% reproducible. I don't know if telling someone to send reports to Microsoft and have them fix the problem is the most reasonable solution. - Robert Dailey On Mon, Nov 21, 2011 at 5:18 PM, David Cole david.c...@kitware.com wrote: Submit/send your crash reports to Microsoft so they can fix it... I haven't heard of a problem like this. Is it 100% reproducible? (i.e. does it happen every time you do this?) On Mon, Nov 21, 2011 at 4:30 PM, Robert Dailey rcdai...@gmail.com wrote: Unfortunately I don't have a whole lot of details to share here, so I'm hoping someone can tell me what steps I can take to debug this issue. I generated about 120 projects in a VC2010 Express solution and opened it. Everything opened fine. I pick any project in the solution, right-click it, and select Build... Visual Studio crashes. I'm running Windows 7 x64 Ultimate and CMake 2.8.6. If I generate for VS7.1 and VS9 using the same scripts, visual studio does not crash in those versions and builds just fine. Note however that I am not using the express versions in those cases. - Robert Dailey -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake / xcode / c++ header files
How can I get the cmake xcode generator to add a /include folder to
generated projects? The cmakelists contain these directives:
SET(${this_target}_HEADER_FILES ./a.h ./b.h)
SET_SOURCE_FILES_PROPERTIES(${this_target}_HEADER_FILES PROPERTIES
HEADER_FILE_ONLY TRUE)
LIST(APPEND ${this_target}_SOURCE_FILES ${${this_target}_HEADER_FILES})
Thx++
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VC2010 Express crashing
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Dailey Sent: Dienstag, 22. November 2011 14:33 To: David Cole Cc: CMake ML Subject: Re: [CMake] VC2010 Express crashing No problem. I'll send a crash report to MS and see what I can figure out. I assume I need to report the crash on the MSDN forums? Never reported a MS bug before so not sure. You can report bugs here https://connect.microsoft.com/VisualStudio/feedback/CreateFeedback.aspx https://connect.microsoft.com/VisualStudio/feedback/CreateFeedback.aspx You may need to register/login to submit the bug. Currently there are 2 different forms where you can submit it , use Visual Studio, .NET and Silverlight form, not Roslyn CTP one. Vladislav -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake / xcode / c++ header files
I have my own macro that I use for this:
MACRO (cmp_IDE_SOURCE_PROPERTIES SOURCE_PATH HEADERS SOURCES INSTALL_FILES)
if (${INSTALL_FILES} EQUAL 1)
INSTALL (FILES ${HEADERS}
DESTINATION include/${SOURCE_PATH}
COMPONENT Headers
)
endif()
STRING(REPLACE / source_group_path ${SOURCE_PATH} )
source_group(${source_group_path} FILES ${HEADERS} ${SOURCES})
#-- The following is needed if we ever start to use OS X Frameworks but only
#-- works on CMake 2.6 and greater
#set_property(SOURCE ${HEADERS}
# PROPERTY MACOSX_PACKAGE_LOCATION Headers/${NAME}
#)
ENDMACRO (cmp_IDE_SOURCE_PROPERTIES NAME HEADERS SOURCES INSTALL_FILES)
And I use it like this:
cmp_IDE_SOURCE_PROPERTIES( include ${${this_target}_HEADER_FILES}
${this_target}_SOURCE_FILES TRUE)
This seems to need CMake 2.8.6 to really work well.
--
Mike Jackson www.bluequartz.net
On Nov 22, 2011, at 8:42 AM, g...@novadsp.com wrote:
How can I get the cmake xcode generator to add a /include folder to generated
projects? The cmakelists contain these directives:
SET(${this_target}_HEADER_FILES ./a.h ./b.h)
SET_SOURCE_FILES_PROPERTIES(${this_target}_HEADER_FILES PROPERTIES
HEADER_FILE_ONLY TRUE)
LIST(APPEND ${this_target}_SOURCE_FILES ${${this_target}_HEADER_FILES})
Thx++
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] global variable vs cache variable
On 11/22/2011 02:14 PM, t m wrote:
Use the cache only if the values need to be persistent. Otherwise I
recommend using a GLOBAL property. See set_property() and get_property().
Michael
Thank you Michael. Looks good. So let me summarize. The workflow
should looks like follow:
1. Top Level CMakeLists.txt:
add_subdirectory( foo )
2. Level 2 foo/CMakeLists.txt
set_property ( GLOBAL P_A PROPERTY some value)
that should read:
set_property(GLOBAL PROPERTY P_A some value)
3. Level 1 CMakeLists.txt
get_property ( VAR_A GLOBAL PROPERY P_A)
message (STATUS VAR_A=${VAR_A})
is that's right?
Yes, that's about right.
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake and Sandboxed Mac OS X app
Hello @everyone,
I want to use cmake and make from the command line (without Xcode) to
build an Mac OS X app which make use of the new sandboxing feature.
I added the following lines, but in the activity monitor the app is still
not sandboxed:
IF(APPLE)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/main.cpp
PROPERTIES OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Info.plist)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/Info.plist
PROPERTIES GENERATED TRUE)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/main.cpp
PROPERTIES OBJECT_DEPENDS
${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}.entitlements)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}.enti
tlements PROPERTIES GENERATED TRUE)
.
.
.
ENDIF(APPLE)
Did I miss something?
Any help would be great.
Thanks in advance
Best Regards
NoRulez
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake / xcode / c++ header files [solved]
excellent suggestion, i will try it out. thank!
On 22/11/2011 14:29, Michael Jackson wrote:
I have my own macro that I use for this:
MACRO (cmp_IDE_SOURCE_PROPERTIES SOURCE_PATH HEADERS SOURCES INSTALL_FILES)
if (${INSTALL_FILES} EQUAL 1)
INSTALL (FILES ${HEADERS}
DESTINATION include/${SOURCE_PATH}
COMPONENT Headers
)
endif()
STRING(REPLACE / source_group_path ${SOURCE_PATH} )
source_group(${source_group_path} FILES ${HEADERS} ${SOURCES})
#-- The following is needed if we ever start to use OS X Frameworks but only
#-- works on CMake 2.6 and greater
#set_property(SOURCE ${HEADERS}
# PROPERTY MACOSX_PACKAGE_LOCATION Headers/${NAME}
#)
ENDMACRO (cmp_IDE_SOURCE_PROPERTIES NAME HEADERS SOURCES INSTALL_FILES)
And I use it like this:
cmp_IDE_SOURCE_PROPERTIES( include ${${this_target}_HEADER_FILES}
${this_target}_SOURCE_FILES TRUE)
This seems to need CMake 2.8.6 to really work well.
--
Mike Jacksonwww.bluequartz.net
On Nov 22, 2011, at 8:42 AM, g...@novadsp.com wrote:
How can I get the cmake xcode generator to add a /include folder to generated
projects? The cmakelists contain these directives:
SET(${this_target}_HEADER_FILES ./a.h ./b.h)
SET_SOURCE_FILES_PROPERTIES(${this_target}_HEADER_FILES PROPERTIES
HEADER_FILE_ONLY TRUE)
LIST(APPEND ${this_target}_SOURCE_FILES ${${this_target}_HEADER_FILES})
Thx++
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Sandboxed Mac OS X app
I have not heard of anybody building a Sandboxed app using CMake yet.
What are the requirements for a Sandboxed app? Is there a
documentation page from Apple that describes what needs to be in the
Info.plist to support Sandboxing?
Thx,
David
On Tue, Nov 22, 2011 at 10:44 AM, NoRulez noru...@me.com wrote:
Hello @everyone,
I want to use cmake and „make“ from the command line (without Xcode) to
build an Mac OS X app which make use of the “new” sandboxing feature.
I added the following lines, but in the activity monitor the app is still
not sandboxed:
IF(APPLE)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/main.cpp
PROPERTIES OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/Info.plist)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/Info.plist
PROPERTIES GENERATED TRUE)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/main.cpp
PROPERTIES OBJECT_DEPENDS
${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}.entitlements)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}.entitlements
PROPERTIES GENERATED TRUE)
.
.
.
ENDIF(APPLE)
Did I miss something?
Any help would be great.
Thanks in advance
Best Regards
NoRulez
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Sandboxed Mac OS X app
On Tue, 22 Nov 2011 11:45:29 -0500, David Cole said: What are the requirements for a Sandboxed app? Is there a documentation page from Apple that describes what needs to be in the Info.plist to support Sandboxing? The main doc is here: http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html It's more than just adding keys in Info.plist, the app also needs to be codesigned, which is typically done by invoking the 'codesign' tool (see man codesign). -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Sandboxed Mac OS X app
Hi Sean, did you know if I also need special compiler and/or linker flags? Best Regards -Ursprüngliche Nachricht- Von: Sean McBride [mailto:s...@rogue-research.com] Gesendet: Dienstag, 22. November 2011 17:56 An: David Cole; NoRulez Cc: CMake MailingList Betreff: Re: [CMake] CMake and Sandboxed Mac OS X app On Tue, 22 Nov 2011 11:45:29 -0500, David Cole said: What are the requirements for a Sandboxed app? Is there a documentation page from Apple that describes what needs to be in the Info.plist to support Sandboxing? The main doc is here: http://developer.apple.com/library/mac/#documentation/Security/Conceptual/A ppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html It's more than just adding keys in Info.plist, the app also needs to be codesigned, which is typically done by invoking the 'codesign' tool (see man codesign). -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Sandboxed Mac OS X app
On Tue, 22 Nov 2011 18:35:42 +0100, NoRulez said: did you know if I also need special compiler and/or linker flags? That's more of an Xcode question than a CMake question... IIRC, no you don't. You just need to add your entitlements file and codesign. But it's been a few months since I played with App Sandbox. It's still half-baked and I gave up on it. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Sandboxed Mac OS X app
IIRC, no you don't Thanks This means that I only have to add the following parameters to my codesign call: --entitlements MyEntitlements.plist Is this correct? Because I already tried this but then if I launch my app the application crashes. The file MyEntitlements.plist contains: ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 dict keycom.apple.security.app-sandbox/key true/ /dict /plist -Ursprüngliche Nachricht- Von: Sean McBride [mailto:s...@rogue-research.com] Gesendet: Dienstag, 22. November 2011 18:38 An: NoRulez; 'David Cole' Cc: 'CMake MailingList' Betreff: Re: AW: [CMake] CMake and Sandboxed Mac OS X app On Tue, 22 Nov 2011 18:35:42 +0100, NoRulez said: did you know if I also need special compiler and/or linker flags? That's more of an Xcode question than a CMake question... IIRC, no you don't. You just need to add your entitlements file and codesign. But it's been a few months since I played with App Sandbox. It's still half-baked and I gave up on it. -- Sean McBride, B. Eng mailto:s...@rogue-research.com s...@rogue-research.com Rogue Research http://www.rogue-research.com www.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] what softwares need to be installed to run ITK/C++ under linux?
Hi everyong: I wanted to learn C++ programming with ITK under linux, does any tell me what softwares/packages that I need to install? I am running a Centos 64-bit linux system. Thanks, ping wang -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] (no subject)
http://nobiofuel.com/affiliate/plugins/SignupActionCommissions/smmfkro.htm -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake, Qt4, Ubuntu and Phonon
As we pointed out in the bug thread located at https://bugs.launchpad.net/ubuntu/+source/phonon/+bug/893170 the FindPhonon script is not portable to Windows. I agree with André's comment: the source of the problem is the Ubuntu way of distributing Qt4 and Phonon. We also have to keep in mind that the official CMake module FindQt4 doesn't actually find Qt4 correctly on Ubuntu. I think this is a problem for both Ubuntu and CMake. The two solutions to this problem I can think of are 1) Patch the FindQt4 script so it can find Phonon correctly when not distributed with Qt4 and 2) Make pressure on the Ubuntu community so it distribute Phonon as a Qt4 (optional) package (like Debian does). I would like to have your feedback on this issue so we can discuss alternative solutions. Feel free to comment on the bug report to make pressure on the Ubuntu community. I would be happy to patch the FindQt4 module if the community agrees on this solution. Regards, -- Félix C. Morency, M.Sc. Plateforme d’analyse et de visualisation d’images Centre Hospitalier Universitaire de Sherbrooke Centre de recherche clinique Étienne-Le Bel Local Z5-3031 | 819.346.1110 ext 16634 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake, Qt4, Ubuntu and Phonon
On Tuesday, November 22, 2011 02:34:55 pm Félix C. Morency wrote: As we pointed out in the bug thread located at https://bugs.launchpad.net/ubuntu/+source/phonon/+bug/893170 the FindPhonon script is not portable to Windows. I agree with André's comment: the source of the problem is the Ubuntu way of distributing Qt4 and Phonon. We also have to keep in mind that the official CMake module FindQt4 doesn't actually find Qt4 correctly on Ubuntu. I think this is a problem for both Ubuntu and CMake. The two solutions to this problem I can think of are 1) Patch the FindQt4 script so it can find Phonon correctly when not distributed with Qt4 and 2) Make pressure on the Ubuntu community so it distribute Phonon as a Qt4 (optional) package (like Debian does). I would like to have your feedback on this issue so we can discuss alternative solutions. Feel free to comment on the bug report to make pressure on the Ubuntu community. I would be happy to patch the FindQt4 module if the community agrees on this solution. Does it work if one is using qmake simply because phonon is in the linker's standard search paths? Or does qmake on Ubuntu know how to find phonon? phonon is treated as a Qt module as far as qmake and FindQt4.cmake are concerned, and not as a 3rd party library, like zlib and others. But, I'm not opposed to modifying FindQt4.cmake, but I have a concern if one builds their own Qt (different version) without phonon, is it OK to find /usr/lib/libphonon.so? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake and Python
Hi all, I don't know if anybody would find this useful or not, but I thought I'd let everybody know about it and if somebody would like to use it, I can figure out the best way to get it out there. We have a fairly extensive python library that we use to setup our code and manipulate our data. Part of this process is generating/manipulating CMake cache files. To that end, I wrote a module that can do the following: - Given a CMakeLists.txt, build a dictionary of available options (possibly including advanced) including the type and default values (and take in some options to turn on before checking for options, to activate if's for example; also allow the caller to specify a prefix they want to include, for instance 'CMAKE' would result in a dictionary only containing CMAKE_* variables). - Given a CMakeCache.txt file, build the above dictionary - Given a dictionary of options (built from above or by hand), write out a script to generate the initial cache (to be used with cmake -C) - Given a dictionary of options, take in another dictionary of options to modify original dictionary with possible include/exclude lists (an example use is to take a dictionary from the user to modify default values, combined with the include/exclude list to say Only let the user change options X, Y, Z regardless of what they tried to change) The final thing it currently does may get left in or stripped out if I release it to people -- it writes a simple python script to execute a code using MPI based on the values for the MPI variables found by CMake. This is because we use it to setup test cases and needed an easy way to determine the MPIEXEC and MAX_PROCS variables. So, if people are interested in using it or expanding it, let me know and I can throw it up on GitHub or something. If it's something useful for inclusion in CMake now or down the road, that can be figured out too. Tim -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ccmake was not created
Hello! Thank you for the help. Here is a part of my CMakeCashe.txt: // --- //Path to a file. CURSES_CURSES_H_PATH:PATH=/usr/include //Path to a library. CURSES_CURSES_LIBRARY:FILEPATH=/usr/lib/libcurses.so //Path to a library. CURSES_EXTRA_LIBRARY:FILEPATH=CURSES_EXTRA_LIBRARY-NOTFOUND //Path to a library. CURSES_FORM_LIBRARY:FILEPATH=/usr/lib/libform.so //Path to a file. CURSES_HAVE_CURSES_H:FILEPATH=/usr/include/curses.h //The curses include path CURSES_INCLUDE_PATH:FILEPATH=CURSES_CURSES_H_PATH-NOTFOUND //The curses library CURSES_LIBRARY:FILEPATH=CURSES_CURSES_LIBRARY-NOTFOUND //Path to a library. CURSES_NCURSES_LIBRARY:FILEPATH=/usr/lib/libncurses.so // --- But these files exist in my system: artemiev@artemiev-desktop:~$ find /usr/lib -name libcurse* /usr/lib/libcurses.so /usr/lib/libcurses.a artemiev@artemiev-desktop:~$ find /usr/lib -name libncurse* /usr/lib/libncurses++.a /usr/lib/libncurses.so /usr/lib/libncurses.a artemiev@artemiev-desktop:~$ find /usr/include -name curse* /usr/include/cursesf.h /usr/include/cursesm.h /usr/include/curses.h /usr/include/cursesw.h /usr/include/cursesp.h /usr/include/cursesapp.h I don't understand why these files cannot be found. Maybe I need to check for some system variables? Mikhail -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v2.8.6-218-g3bbe46d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 3bbe46daa27a2f405bf97622ad30fd6090e2958e (commit) from ad9bffdc3c1b43e0a3c3f47e9ee8d3bff487324e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3bbe46daa27a2f405bf97622ad30fd6090e2958e commit 3bbe46daa27a2f405bf97622ad30fd6090e2958e Author: KWSys Robot kwro...@kitware.com AuthorDate: Tue Nov 22 00:05:06 2011 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Tue Nov 22 00:05:06 2011 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 30a0b06..1df5ca9 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 11) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 21) +SET(KWSYS_DATE_STAMP_DAY 22) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.6-1977-ga4d3147
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via a4d31477cfb1cc371e5d7387d742dbe6df838005 (commit)
via e8b5b222b6827e8db490bcc78ea9f967b5c4b247 (commit)
via 69ac7cab9dad260a9feee00caea1813b5b76ebf5 (commit)
via a364dfbc83979d556848b1e54b2c637cfbdabb46 (commit)
from ddf16039f8f093f4d5aa43405ae1c22668b5246a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a4d31477cfb1cc371e5d7387d742dbe6df838005
commit a4d31477cfb1cc371e5d7387d742dbe6df838005
Merge: ddf1603 e8b5b22
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Tue Nov 22 13:27:19 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 22 13:27:19 2011 -0500
Merge topic 'RestoreAutmocKDECompatibility' into next
e8b5b22 automoc: add test for including a moc_abc_p.cpp file
69ac7ca automoc: add test for including the moc file from another header
a364dfb automoc: add a test for including both abc.moc and moc_abc.cpp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8b5b222b6827e8db490bcc78ea9f967b5c4b247
commit e8b5b222b6827e8db490bcc78ea9f967b5c4b247
Author: Alex Neundorf neund...@kde.org
AuthorDate: Tue Nov 22 19:24:39 2011 +0100
Commit: Alex Neundorf neund...@kde.org
CommitDate: Tue Nov 22 19:24:39 2011 +0100
automoc: add test for including a moc_abc_p.cpp file
Alex
diff --git a/Tests/QtAutomoc/abc.cpp b/Tests/QtAutomoc/abc.cpp
index 25071cd..4bbc769 100644
--- a/Tests/QtAutomoc/abc.cpp
+++ b/Tests/QtAutomoc/abc.cpp
@@ -13,6 +13,7 @@
#include abc.h
+#include abc_p.h
#include stdio.h
@@ -35,11 +36,14 @@ void Abc::doAbc()
{
PrintAbc pa;
pa.print();
+ AbcP abcP;
+ abcP.doAbcP();
}
// check that including the moc file for the cpp file and the header works:
#include abc.moc
#include moc_abc.cpp
+#include moc_abc_p.cpp
// check that including a moc file from another header works:
#include moc_xyz.cpp
diff --git a/Tests/QtAutomoc/abc.cpp b/Tests/QtAutomoc/abc_p.h
similarity index 62%
copy from Tests/QtAutomoc/abc.cpp
copy to Tests/QtAutomoc/abc_p.h
index 25071cd..952fff3 100644
--- a/Tests/QtAutomoc/abc.cpp
+++ b/Tests/QtAutomoc/abc_p.h
@@ -11,35 +11,20 @@
See the License for more information.
*/
+#ifndef ABC_P_H
+#define ABC_P_H
-#include abc.h
+#include QObject
#include stdio.h
-class PrintAbc : public QObject
+class AbcP : public QObject
{
Q_OBJECT
public:
-PrintAbc():QObject() {}
+AbcP() {}
public slots:
-void print() const { printf(abc\n); }
+void doAbcP() { printf(I am private abc !\n); }
};
-Abc::Abc()
-:QObject()
-{
-}
-
-
-void Abc::doAbc()
-{
- PrintAbc pa;
- pa.print();
-}
-
-// check that including the moc file for the cpp file and the header works:
-#include abc.moc
-#include moc_abc.cpp
-
-// check that including a moc file from another header works:
-#include moc_xyz.cpp
+#endif
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=69ac7cab9dad260a9feee00caea1813b5b76ebf5
commit 69ac7cab9dad260a9feee00caea1813b5b76ebf5
Author: Alex Neundorf neund...@kde.org
AuthorDate: Tue Nov 22 19:19:31 2011 +0100
Commit: Alex Neundorf neund...@kde.org
CommitDate: Tue Nov 22 19:19:31 2011 +0100
automoc: add test for including the moc file from another header
including moc_xyz.cpp in abc.cpp should run moc on xyz.h (and
include the file in abc.cpp)
Alex
diff --git a/Tests/QtAutomoc/CMakeLists.txt b/Tests/QtAutomoc/CMakeLists.txt
index c81ac11..9f02618 100644
--- a/Tests/QtAutomoc/CMakeLists.txt
+++ b/Tests/QtAutomoc/CMakeLists.txt
@@ -13,7 +13,7 @@ add_definitions(-DFOO)
# create an executable and a library target, both requiring automoc:
add_library(codeeditorLib STATIC codeeditor.cpp)
-add_executable(foo main.cpp calwidget.cpp foo.cpp blub.cpp bar.cpp abc.cpp)
+add_executable(foo main.cpp calwidget.cpp foo.cpp blub.cpp bar.cpp abc.cpp
xyz.cpp)
set_target_properties(foo codeeditorLib PROPERTIES AUTOMOC TRUE)
diff --git a/Tests/QtAutomoc/abc.cpp b/Tests/QtAutomoc/abc.cpp
index f922615..25071cd 100644
--- a/Tests/QtAutomoc/abc.cpp
+++ b/Tests/QtAutomoc/abc.cpp
@@ -37,5 +37,9 @@ void Abc::doAbc()
pa.print();
}
+// check that including the moc file for the cpp file and the header works:
#include abc.moc
#include moc_abc.cpp
+
+// check that including a moc file from another header works:
+#include moc_xyz.cpp
diff --git a/Tests/QtAutomoc/main.cpp b/Tests/QtAutomoc/main.cpp
index 5414daf..7eb29a3 100644
--- a/Tests/QtAutomoc/main.cpp
+++
[Cmake-commits] CMake branch, next, updated. v2.8.6-1981-g31a9140
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 31a9140041a1dd89a02f5aeef9e1ca8785f7 (commit)
via bc7560e6e56d1f6fa65745cf5c1206192fb77b04 (commit)
via 30fd8e603a52b7230e0b716d8120fc01551c8a4f (commit)
via 80dfbc99f4b04b5eaea9111fa014f07603a8db16 (commit)
from a4d31477cfb1cc371e5d7387d742dbe6df838005 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=31a9140041a1dd89a02f5aeef9e1ca8785f7
commit 31a9140041a1dd89a02f5aeef9e1ca8785f7
Merge: a4d3147 bc7560e
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Tue Nov 22 14:57:04 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 22 14:57:04 2011 -0500
Merge topic 'AutomocIncludedDotMocFileHandling' into next
bc7560e automoc: add test for including a moc_abc_p.cpp file
30fd8e6 automoc: add test for including the moc file from another header
80dfbc9 automoc: add a test for including both abc.moc and moc_abc.cpp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc7560e6e56d1f6fa65745cf5c1206192fb77b04
commit bc7560e6e56d1f6fa65745cf5c1206192fb77b04
Author: Alex Neundorf neund...@kde.org
AuthorDate: Tue Nov 22 19:24:39 2011 +0100
Commit: Alex Neundorf neund...@kde.org
CommitDate: Tue Nov 22 20:52:21 2011 +0100
automoc: add test for including a moc_abc_p.cpp file
Alex
diff --git a/Tests/QtAutomoc/abc.cpp b/Tests/QtAutomoc/abc.cpp
index 25071cd..4bbc769 100644
--- a/Tests/QtAutomoc/abc.cpp
+++ b/Tests/QtAutomoc/abc.cpp
@@ -13,6 +13,7 @@
#include abc.h
+#include abc_p.h
#include stdio.h
@@ -35,11 +36,14 @@ void Abc::doAbc()
{
PrintAbc pa;
pa.print();
+ AbcP abcP;
+ abcP.doAbcP();
}
// check that including the moc file for the cpp file and the header works:
#include abc.moc
#include moc_abc.cpp
+#include moc_abc_p.cpp
// check that including a moc file from another header works:
#include moc_xyz.cpp
diff --git a/Tests/QtAutomoc/abc.cpp b/Tests/QtAutomoc/abc_p.h
similarity index 62%
copy from Tests/QtAutomoc/abc.cpp
copy to Tests/QtAutomoc/abc_p.h
index 25071cd..952fff3 100644
--- a/Tests/QtAutomoc/abc.cpp
+++ b/Tests/QtAutomoc/abc_p.h
@@ -11,35 +11,20 @@
See the License for more information.
*/
+#ifndef ABC_P_H
+#define ABC_P_H
-#include abc.h
+#include QObject
#include stdio.h
-class PrintAbc : public QObject
+class AbcP : public QObject
{
Q_OBJECT
public:
-PrintAbc():QObject() {}
+AbcP() {}
public slots:
-void print() const { printf(abc\n); }
+void doAbcP() { printf(I am private abc !\n); }
};
-Abc::Abc()
-:QObject()
-{
-}
-
-
-void Abc::doAbc()
-{
- PrintAbc pa;
- pa.print();
-}
-
-// check that including the moc file for the cpp file and the header works:
-#include abc.moc
-#include moc_abc.cpp
-
-// check that including a moc file from another header works:
-#include moc_xyz.cpp
+#endif
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=30fd8e603a52b7230e0b716d8120fc01551c8a4f
commit 30fd8e603a52b7230e0b716d8120fc01551c8a4f
Author: Alex Neundorf neund...@kde.org
AuthorDate: Tue Nov 22 19:19:31 2011 +0100
Commit: Alex Neundorf neund...@kde.org
CommitDate: Tue Nov 22 20:52:13 2011 +0100
automoc: add test for including the moc file from another header
including moc_xyz.cpp in abc.cpp should run moc on xyz.h (and
include the file in abc.cpp)
Alex
diff --git a/Tests/QtAutomoc/CMakeLists.txt b/Tests/QtAutomoc/CMakeLists.txt
index c81ac11..9f02618 100644
--- a/Tests/QtAutomoc/CMakeLists.txt
+++ b/Tests/QtAutomoc/CMakeLists.txt
@@ -13,7 +13,7 @@ add_definitions(-DFOO)
# create an executable and a library target, both requiring automoc:
add_library(codeeditorLib STATIC codeeditor.cpp)
-add_executable(foo main.cpp calwidget.cpp foo.cpp blub.cpp bar.cpp abc.cpp)
+add_executable(foo main.cpp calwidget.cpp foo.cpp blub.cpp bar.cpp abc.cpp
xyz.cpp)
set_target_properties(foo codeeditorLib PROPERTIES AUTOMOC TRUE)
diff --git a/Tests/QtAutomoc/abc.cpp b/Tests/QtAutomoc/abc.cpp
index f922615..25071cd 100644
--- a/Tests/QtAutomoc/abc.cpp
+++ b/Tests/QtAutomoc/abc.cpp
@@ -37,5 +37,9 @@ void Abc::doAbc()
pa.print();
}
+// check that including the moc file for the cpp file and the header works:
#include abc.moc
#include moc_abc.cpp
+
+// check that including a moc file from another header works:
+#include moc_xyz.cpp
diff --git a/Tests/QtAutomoc/main.cpp b/Tests/QtAutomoc/main.cpp
index 5414daf..7eb29a3 100644
--- a/Tests/QtAutomoc/main.cpp
+++
[Cmake-commits] CMake branch, next, updated. v2.8.6-1996-g2e84d8e
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 2e84d8e613c22677e30414c236dd4f106fdc9a97 (commit)
via 0599c5f546c8b3e04c0dd9fcdc19a6b3825849a7 (commit)
via 0a6705cbda8171667c4b37872136cd102ccc328c (commit)
via 24b1feb5ca9dbc3461d373e4de30a33157f81375 (commit)
via 1ec3fa00c920ca0d13ef30965ce2560ecd006e0c (commit)
via 6495b595c4953ce29e66ff4919d69a74300c3532 (commit)
via 8302608a744c3a4df3495f8db88784fb3f04660f (commit)
via 9fb1a9cf1dc45672b38350f2c4ae560359521566 (commit)
via b0853b5fae2681f31f023a37d04cea1209b34dbd (commit)
via 9da8340a6d68ec1dce9248d0d83f59ba6f41003e (commit)
via 23b3df76a069ab314a4828ad651f1a14319ff660 (commit)
via 2e9c26cf9616fead92ec65eefc696bcf9761b996 (commit)
via 293a7f4e2ae9b458d3efefcfe133d0ad5320a1b2 (commit)
via 46ab0561fc29446a736985816b005200aad9489c (commit)
via 38771d3bdf51b81d46578e0c81ebddbdea0ce3b2 (commit)
from 31a9140041a1dd89a02f5aeef9e1ca8785f7 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2e84d8e613c22677e30414c236dd4f106fdc9a97
commit 2e84d8e613c22677e30414c236dd4f106fdc9a97
Merge: 31a9140 0599c5f
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 22 15:04:35 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 22 15:04:35 2011 -0500
Merge topic 'crypto-hash' into next
0599c5f sha2: Zero entire SHA_CTX structure during cleanup
0a6705c sha2: Suppress -Wcast-align warning from Clang
24b1feb sha2: Cast safe conversions to smaller integer types
1ec3fa0 Merge branch 'update-KWIML' into crypto-hash
6495b59 cmCryptoHash: Add virtual destructor
8302608 Fix CMake.File hash test for CRLF checkouts
9fb1a9c sha2: Wrap long lines in third-party declarations
b0853b5 Disable file() and string() hash commands during bootstrap
9da8340 sha2: Suppress Borland warnings in third-party code
23b3df7 sha2: Use KWIML fixed-size integer constant macros
2e9c26c Add string(MD5) and string(SHA*) commands to compute hashes
293a7f4 cmCryptoHash: Provide factory New method
46ab056 sha2: Use static const instead of const static declarations
38771d3 Add file(SHA*) commands to compute cryptographic hashes
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0599c5f546c8b3e04c0dd9fcdc19a6b3825849a7
commit 0599c5f546c8b3e04c0dd9fcdc19a6b3825849a7
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Nov 17 11:18:08 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Nov 17 11:18:08 2011 -0500
sha2: Zero entire SHA_CTX structure during cleanup
Convert lines of the form
MEMSET_BZERO(context, sizeof(context));
to the correct form
MEMSET_BZERO(context, sizeof(*context));
as suggested by Clang.
diff --git a/Source/cm_sha2.c b/Source/cm_sha2.c
index b1798a8..12c39ed 100644
--- a/Source/cm_sha2.c
+++ b/Source/cm_sha2.c
@@ -704,7 +704,7 @@ void SHA1_Final(sha_byte digest[], SHA_CTX* context) {
* No digest buffer, so we can do nothing
* except clean up and go home
*/
- MEMSET_BZERO(context, sizeof(context));
+ MEMSET_BZERO(context, sizeof(*context));
return;
}
@@ -760,7 +760,7 @@ void SHA1_Final(sha_byte digest[], SHA_CTX* context) {
#endif
/* Clean up: */
- MEMSET_BZERO(context, sizeof(context));
+ MEMSET_BZERO(context, sizeof(*context));
}
char *SHA1_End(SHA_CTX* context, char buffer[]) {
@@ -780,7 +780,7 @@ char *SHA1_End(SHA_CTX* context, char buffer[]) {
}
*buffer = (char)0;
} else {
- MEMSET_BZERO(context, sizeof(context));
+ MEMSET_BZERO(context, sizeof(*context));
}
MEMSET_BZERO(digest, SHA1_DIGEST_LENGTH);
return buffer;
@@ -1099,7 +1099,7 @@ void SHA256_Final(sha_byte digest[], SHA_CTX* context) {
}
/* Clean up state data: */
- MEMSET_BZERO(context, sizeof(context));
+ MEMSET_BZERO(context, sizeof(*context));
}
char *SHA256_End(SHA_CTX* context, char buffer[]) {
@@ -1119,7 +1119,7 @@ char *SHA256_End(SHA_CTX* context, char buffer[]) {
}
*buffer = (char)0;
} else {
- MEMSET_BZERO(context, sizeof(context));
+ MEMSET_BZERO(context, sizeof(*context));
}
MEMSET_BZERO(digest, SHA256_DIGEST_LENGTH);
return buffer;
@@ -1173,7 +1173,7 @@ void SHA224_Final(sha_byte
[Cmake-commits] CMake branch, next, updated. v2.8.6-1998-gd7cb90e
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via d7cb90e1bb3747876c53f2f006d6b5ce5399c22f (commit)
via 614595f2074c57069812b5bb6c3ccb0f067945ce (commit)
from 2e84d8e613c22677e30414c236dd4f106fdc9a97 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d7cb90e1bb3747876c53f2f006d6b5ce5399c22f
commit d7cb90e1bb3747876c53f2f006d6b5ce5399c22f
Merge: 2e84d8e 614595f
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 22 16:02:00 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 22 16:02:00 2011 -0500
Merge topic 'CheckImportedFileExistenceInConfigDotCMakeFiles' into next
614595f install(EXPORT): Remove leftover export() command changes
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=614595f2074c57069812b5bb6c3ccb0f067945ce
commit 614595f2074c57069812b5bb6c3ccb0f067945ce
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 22 16:00:09 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Nov 22 16:00:09 2011 -0500
install(EXPORT): Remove leftover export() command changes
The implementation of imported file existence verification was
originally done for both install(EXPORT) and export() but the latter was
removed since not all configurations may be available in a build tree.
Remove remnants of the export() implementation.
diff --git a/Source/cmExportBuildFileGenerator.cxx
b/Source/cmExportBuildFileGenerator.cxx
index 1f8a2e2..7e73e36 100644
--- a/Source/cmExportBuildFileGenerator.cxx
+++ b/Source/cmExportBuildFileGenerator.cxx
@@ -68,9 +68,7 @@ cmExportBuildFileGenerator
// Collect import properties for this target.
cmTarget* target = *tei;
ImportPropertyMap properties;
-std::setstd::string importedLocations;
-this-SetImportLocationProperty(config, suffix, target, properties,
-importedLocations);
+this-SetImportLocationProperty(config, suffix, target, properties);
if(!properties.empty())
{
// Get the rest of the target details.
@@ -87,15 +85,13 @@ cmExportBuildFileGenerator
this-GenerateImportPropertyCode(os, config, target, properties);
}
}
-
}
//
void
cmExportBuildFileGenerator
::SetImportLocationProperty(const char* config, std::string const suffix,
-cmTarget* target, ImportPropertyMap properties,
-std::setstd::string importedLocations)
+cmTarget* target, ImportPropertyMap properties)
{
// Get the makefile in which to lookup target information.
cmMakefile* mf = target-GetMakefile();
@@ -114,7 +110,6 @@ cmExportBuildFileGenerator
value = target-GetFullPath(config, false, true);
}
properties[prop] = value;
- importedLocations.insert(prop);
}
// Check whether this is a DLL platform.
@@ -131,7 +126,6 @@ cmExportBuildFileGenerator
prop += suffix;
std::string value = target-GetFullPath(config, true);
properties[prop] = value;
-importedLocations.insert(prop);
}
}
diff --git a/Source/cmExportBuildFileGenerator.h
b/Source/cmExportBuildFileGenerator.h
index 18be68e..0f37626 100644
--- a/Source/cmExportBuildFileGenerator.h
+++ b/Source/cmExportBuildFileGenerator.h
@@ -52,8 +52,7 @@ protected:
void SetImportLocationProperty(const char* config,
std::string const suffix,
cmTarget* target,
- ImportPropertyMap properties,
- std::setstd::string importedLocations);
+ ImportPropertyMap properties);
std::vectorcmTarget* const* Exports;
cmExportCommand* ExportCommand;
---
Summary of changes:
Source/cmExportBuildFileGenerator.cxx | 10 ++
Source/cmExportBuildFileGenerator.h |3 +--
2 files changed, 3 insertions(+), 10 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.6-2001-gfe18977
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via fe18977b5f4e12e07dd4693a038b5b407ee0a0c2 (commit)
via 5c03438661c285a7cc5f1e691198ac4e8a68a8f6 (commit)
via a2be068c75890a9b6723c0bbb2d32a108cb84eed (commit)
from d7cb90e1bb3747876c53f2f006d6b5ce5399c22f (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe18977b5f4e12e07dd4693a038b5b407ee0a0c2
commit fe18977b5f4e12e07dd4693a038b5b407ee0a0c2
Merge: d7cb90e 5c03438
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 22 16:02:58 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 22 16:02:58 2011 -0500
Merge topic 'CheckImportedFileExistenceInConfigDotCMakeFiles' into next
5c03438 install(EXPORT): Improve target import failure message format
a2be068 install(EXPORT): Enforce existence of imported target files
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5c03438661c285a7cc5f1e691198ac4e8a68a8f6
commit 5c03438661c285a7cc5f1e691198ac4e8a68a8f6
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Nov 17 16:39:24 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Nov 22 15:55:04 2011 -0500
install(EXPORT): Improve target import failure message format
diff --git a/Source/cmExportFileGenerator.cxx b/Source/cmExportFileGenerator.cxx
index 373..c4f5dfb 100644
--- a/Source/cmExportFileGenerator.cxx
+++ b/Source/cmExportFileGenerator.cxx
@@ -385,19 +385,16 @@
cmExportFileGenerator::GenerateImportedFileCheckLoop(std::ostream os)
FOREACH(target ${_IMPORT_CHECK_TARGETS} )\n
FOREACH(file ${_IMPORT_CHECK_FILES_FOR_${target}} )\n
IF(NOT EXISTS \${file}\ )\n
- MESSAGE(FATAL_ERROR \The imported target \\\${target}\\\
-references the file \\\${file}\\\, but this file does not exist.
-There are multiple possible reasons:\n
- * The file \\\${file}\\\ has been manually
-deleted, renamed or moved to another location.\n
- * A previous install or uninstall procedure did not complete
- successfully.\n
- * The installation package was faulty, and contained\n
-\\\${CMAKE_CURRENT_LIST_FILE}n
-but not\n
-\\\${file}n
-which must always be installed together.\\n\\n
- )\n
+ MESSAGE(FATAL_ERROR \The imported target \\\${target}\\\
+ references the file\n
+ \\\${file}n
+but this file does not exist. Possible reasons include:\n
+* The file was deleted, renamed, or moved to another location.\n
+* An install or uninstall procedure did not complete successfully.\n
+* The installation package was faulty and contained\n
+ \\\${CMAKE_CURRENT_LIST_FILE}n
+but not all the files it references.\n
+\)\n
ENDIF()\n
ENDFOREACH()\n
UNSET(_IMPORT_CHECK_FILES_FOR_${target})\n
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a2be068c75890a9b6723c0bbb2d32a108cb84eed
commit a2be068c75890a9b6723c0bbb2d32a108cb84eed
Author: Alex Neundorf neund...@kde.org
AuthorDate: Sat Nov 12 18:12:07 2011 +0100
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Nov 22 15:55:00 2011 -0500
install(EXPORT): Enforce existence of imported target files
Typical packageConfig.cmake files for find_package() rely only on the
files generated by install(EXPORT). They might be wrong, for whatever
reasons, like people manually deleted files, projects were packaged
wrong by distributions, whatever. To protect against this, add checks
that the file locations we are importing actually exist on disk.
Alex
diff --git a/Source/cmExportFileGenerator.cxx b/Source/cmExportFileGenerator.cxx
index 9e5c91e..373 100644
--- a/Source/cmExportFileGenerator.cxx
+++ b/Source/cmExportFileGenerator.cxx
@@ -368,3 +368,69 @@ cmExportFileGenerator
os)\n
\n;
}
+
+
+//
+void
+cmExportFileGenerator::GenerateImportedFileCheckLoop(std::ostream os)
+{
+ // Add code which verifies at cmake time that the file which is being
+ // imported actually exists on disk. This should in theory always be theory
+ // case, but still when packages are split into normal and development
+ // packages this might get broken (e.g. the Config.cmake could be part of
+ // the non-development package, something similar happened to me without
+ // on SUSE with a mysql pkg-config file, which claimed everything is fine,
+ // but the
[Cmake-commits] CMake branch, master, updated. v2.8.6-222-ge8fc3bc
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via e8fc3bc8d04c8cf64f4c7ed3816126777925660b (commit) via 65dde30dddbe495877a3ecfef5a2d0015449b69c (commit) via e48fcfffa36ca34703a4c366cb96593373234faa (commit) via ecb4459e31a0defec084ca0a02e0450da718afdb (commit) from 3bbe46daa27a2f405bf97622ad30fd6090e2958e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8fc3bc8d04c8cf64f4c7ed3816126777925660b commit e8fc3bc8d04c8cf64f4c7ed3816126777925660b Merge: 3bbe46d 65dde30 Author: David Cole david.c...@kitware.com AuthorDate: Tue Nov 22 16:23:14 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Nov 22 16:23:14 2011 -0500 Merge topic 'FixGettextPoProcessingWithMultipleDots' 65dde30 FindGettext: two more fixes for files with multiple dots e48fcff -make GETTEXT_PROCESS_PO_FILES() work with files with multiple dots ecb4459 Strip trailing whitespace --- Summary of changes: Modules/FindGettext.cmake | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.6-224-g636740c
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 636740c478068685727ffe03f6e469418ca42282 (commit) via 46c70540ede37c5f2ebeeeba4178340abf92fadb (commit) from e8fc3bc8d04c8cf64f4c7ed3816126777925660b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=636740c478068685727ffe03f6e469418ca42282 commit 636740c478068685727ffe03f6e469418ca42282 Merge: e8fc3bc 46c7054 Author: David Cole david.c...@kitware.com AuthorDate: Tue Nov 22 16:23:23 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Nov 22 16:23:23 2011 -0500 Merge topic 'fix-12445-add-call-for-batch-files-vs10' 46c7054 VS: Use call keyword with .cmd and .bat file custom commands (#12445) --- Summary of changes: Source/cmLocalVisualStudioGenerator.cxx | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.6-227-ge9547ef
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via e9547efa96ab8f1b28914749fd80dfa7d43ca998 (commit) via 20cb5edbcaaf89c35638911c27e6aec1c7fc022f (commit) via f30f9a500c5e5aeb053c41307dab9987735570dd (commit) from 636740c478068685727ffe03f6e469418ca42282 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e9547efa96ab8f1b28914749fd80dfa7d43ca998 commit e9547efa96ab8f1b28914749fd80dfa7d43ca998 Merge: 636740c 20cb5ed Author: David Cole david.c...@kitware.com AuthorDate: Tue Nov 22 16:23:31 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Nov 22 16:23:31 2011 -0500 Merge topic 'FindBISON-version-regex' 20cb5ed FindBISON: Fix matching output of bison --version f30f9a5 FindBISON: Fix bison++ version parsing to avoid Offending entry --- Summary of changes: Modules/FindBISON.cmake | 13 +++-- 1 files changed, 11 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.6-229-gf4e266f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via f4e266f41fd0bf390f9e344dd14f870116f6b772 (commit) via df0f302485c6f93a473e1958830b69b9c165b01a (commit) from e9547efa96ab8f1b28914749fd80dfa7d43ca998 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f4e266f41fd0bf390f9e344dd14f870116f6b772 commit f4e266f41fd0bf390f9e344dd14f870116f6b772 Merge: e9547ef df0f302 Author: David Cole david.c...@kitware.com AuthorDate: Tue Nov 22 16:23:36 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Nov 22 16:23:36 2011 -0500 Merge topic 'FindPNG_Provide_PNG_INCLUDE_DIRS_Variable' df0f302 FindPNG: provide PNG_INCLUDE_DIRS, as the readme.txt says (#11312) --- Summary of changes: Modules/FindPNG.cmake | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.6-231-gf0419b4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via f0419b439a0ae8945cc39fbae22ea83ad7f0af74 (commit) via 92af1dad0652951e8f7adc1a4a59527bd98435fa (commit) from f4e266f41fd0bf390f9e344dd14f870116f6b772 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0419b439a0ae8945cc39fbae22ea83ad7f0af74 commit f0419b439a0ae8945cc39fbae22ea83ad7f0af74 Merge: f4e266f 92af1da Author: David Cole david.c...@kitware.com AuthorDate: Tue Nov 22 16:23:48 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Nov 22 16:23:48 2011 -0500 Merge topic 'fix-11792-improve-ctest-site-handling' 92af1da CTest: Disallow problem chars in build and site names (#11792) --- Summary of changes: Source/cmCTest.cxx | 57 ++- Source/cmCTest.h |4 +++ 2 files changed, 55 insertions(+), 6 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.6-242-g7db42fc
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 7db42fc2559ec2692c36cf25f781f50dd48b7f44 (commit)
via ec358d17a77635a59aa09c5dbd7a6cd3b0cf000d (commit)
via b421c2477c4c4f9d4c93997661f1698812cdae36 (commit)
via 5796f88d92832739889cc613d911d4d581b29365 (commit)
via ae7cf91b1376cc313dc39e41c7d3e2026ac79b6b (commit)
via aaf376594cf4ae1d541189a2789382db47aa5d7b (commit)
via 9ccd639ad70c65b844f6610c5ae08a63e25f6806 (commit)
via 8be93fc487064c5b417ab9b0ebd4e027a5e6b9ea (commit)
from 7b1b13c8f005362914796e97551800c63bca393a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7db42fc2559ec2692c36cf25f781f50dd48b7f44
commit 7db42fc2559ec2692c36cf25f781f50dd48b7f44
Merge: 7b1b13c ec358d1
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Nov 22 16:24:04 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 22 16:24:04 2011 -0500
Merge topic 'update-KWIML'
ec358d1 Merge branch 'upstream-kwiml' into update-KWIML
b421c24 KWIML: Avoid MSVC linker warning about not using C++ runtime
5796f88 Merge branch 'upstream-kwiml' into update-KWIML
ae7cf91 KWIML: Teach ABI.h about PGI compiler
aaf3765 Merge branch 'upstream-kwiml' into update-KWIML
9ccd639 KWIML: Ignore _LONGLONG on MS compiler
8be93fc KWIML: Test header inclusion after system headers
---
Summary of changes:
Utilities/KWIML/ABI.h.in |7 ++-
Utilities/KWIML/test/CMakeLists.txt|2 ++
Utilities/KWIML/test/test.c|4
.../test/{test_INT_CXX.cxx = test_include_C.c}| 12 ++--
.../{test_ABI_CXX.cxx = test_include_CXX.cxx} | 18 --
5 files changed, 30 insertions(+), 13 deletions(-)
copy Utilities/KWIML/test/{test_INT_CXX.cxx = test_include_C.c} (81%)
copy Utilities/KWIML/test/{test_ABI_CXX.cxx = test_include_CXX.cxx} (62%)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.6-2011-g4d5ece3
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 4d5ece3c047ec2a5d56e03888116a430ecf2a4cc (commit) via d9df0cca66543610472f5979cfce73765b7e281a (commit) via 7db42fc2559ec2692c36cf25f781f50dd48b7f44 (commit) via 7b1b13c8f005362914796e97551800c63bca393a (commit) via f0419b439a0ae8945cc39fbae22ea83ad7f0af74 (commit) via f4e266f41fd0bf390f9e344dd14f870116f6b772 (commit) via e9547efa96ab8f1b28914749fd80dfa7d43ca998 (commit) via 636740c478068685727ffe03f6e469418ca42282 (commit) via e8fc3bc8d04c8cf64f4c7ed3816126777925660b (commit) via 3bbe46daa27a2f405bf97622ad30fd6090e2958e (commit) from fe18977b5f4e12e07dd4693a038b5b407ee0a0c2 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d5ece3c047ec2a5d56e03888116a430ecf2a4cc commit 4d5ece3c047ec2a5d56e03888116a430ecf2a4cc Merge: fe18977 d9df0cc Author: David Cole david.c...@kitware.com AuthorDate: Tue Nov 22 16:25:03 2011 -0500 Commit: David Cole david.c...@kitware.com CommitDate: Tue Nov 22 16:25:03 2011 -0500 Merge branch 'master' into next --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.6-2015-g99966be
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 99966be1f7e2497bfca909db9232e64351687865 (commit)
via ff35ae79e208a705575f8c1aadd4666a00a352db (commit)
via 914382224d34cfb86a67c8191b6e7b3a3e918f88 (commit)
via cf64218eeb7dbe8a0d71292c42df63c4cb982fed (commit)
from 4d5ece3c047ec2a5d56e03888116a430ecf2a4cc (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=99966be1f7e2497bfca909db9232e64351687865
commit 99966be1f7e2497bfca909db9232e64351687865
Merge: 4d5ece3 ff35ae7
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 22 17:04:45 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 22 17:04:45 2011 -0500
Merge topic 'test-target_link_libraries' into next
ff35ae7 Merge branch 'target-link-libraries-interfaces' into
test-target_link_libraries
9143822 target_link_libraries: Add LINK_(PUBLIC|PRIVATE) options
cf64218 target_link_libraries: Trim trailing whitespace
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ff35ae79e208a705575f8c1aadd4666a00a352db
commit ff35ae79e208a705575f8c1aadd4666a00a352db
Merge: 1e55661 9143822
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 22 16:54:53 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Nov 22 16:55:30 2011 -0500
Merge branch 'target-link-libraries-interfaces' into
test-target_link_libraries
Conflicts:
Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
diff --cc Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
index fdd53eb,1faa888..6df1b4c
--- a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
+++ b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
@@@ -13,271 -13,46 +13,315 @@@ add_executable
${CMAKE_CURRENT_BINARY_DIR}/main.cxx
)
+ macro(ASSERT_PROPERTY _target _property _value)
+ get_target_property(_out ${_target} ${_property})
+ if (NOT _out)
+ set(_out )
+ endif()
+ if (NOT ${_out} STREQUAL ${_value})
+ message(SEND_ERROR Target ${_target} does not have property ${_property}
with value ${_value}. Actual value: ${_out})
+ endif()
+ endmacro()
+
+ include(GenerateExportHeader)
+ set(CMAKE_INCLUDE_CURRENT_DIR ON)
+
+ add_library(depA SHARED depA.cpp)
+ generate_export_header(depA)
+
+ add_library(depB SHARED depB.cpp)
+ generate_export_header(depB)
+
+ target_link_libraries(depB LINK_PRIVATE depA)
+
+ add_library(depC SHARED depC.cpp)
+ generate_export_header(depC)
+
+ target_link_libraries(depC LINK_PUBLIC depA)
+
+ assert_property(depA LINK_INTERFACE_LIBRARIES )
+ assert_property(depB LINK_INTERFACE_LIBRARIES )
+ assert_property(depC LINK_INTERFACE_LIBRARIES depA)
+
+ add_executable(targetA targetA.cpp)
+
+ target_link_libraries(targetA LINK_INTERFACE_LIBRARIES depA depB)
+
+ assert_property(targetA LINK_INTERFACE_LIBRARIES depA;depB)
+
+ set_target_properties(targetA PROPERTIES LINK_INTERFACE_LIBRARIES )
+
+ assert_property(targetA LINK_INTERFACE_LIBRARIES )
+
+ target_link_libraries(targetA depB depC)
+
+ assert_property(targetA LINK_INTERFACE_LIBRARIES )
++
+try_compile(LINK_INTERFACE_LIBRARIES_FAILS
+ ${CMAKE_CURRENT_BINARY_DIR}/control_point
+ ${CMAKE_CURRENT_SOURCE_DIR}/control_point
+ control_point
+)
+
+if (LINK_INTERFACE_LIBRARIES_FAILS)
+ message(\n\n###\nTHIS PLATFORM DOES NOT SUPPORT
LINK_INTERFACE_LIBRARIES\n\n)
+ return()
+endif()
+
+set(Bools True False)
+
+foreach(B1 ${Bools})
+ foreach(B2 ${Bools})
+execute_process(COMMAND ${CMAKE_COMMAND} -E copy_directory
+ ${CMAKE_CURRENT_SOURCE_DIR}/libs
+ ${CMAKE_CURRENT_BINARY_DIR}/libs_${B1}_${B2}
+)
+ endforeach()
+endforeach()
+
+foreach(B1 ${Bools})
+ file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/libs_True_${B1}/CMakeLists.txt
+set(CMAKE_LINK_INTERFACE_LIBRARIES \\)\n
+ )
+endforeach()
+
+foreach(B1 ${Bools})
+ foreach(B2 ${Bools})
+file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/libs_${B1}_${B2}/CMakeLists.txt
+
+ add_library(libA SHARED classA.cpp)\n
+ add_library(libB SHARED classB.cpp)\n
+ add_library(libC SHARED classC.cpp)\n
+
+ generate_export_header(libA)\n
+ generate_export_header(libB)\n
+ generate_export_header(libC)\n
+
+ target_link_libraries(libB libA)\n
+ target_link_libraries(libC libA libB)\n
+)
+ endforeach()
+endforeach()
+
+foreach(B1 ${Bools})
+ file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/libs_${B1}_True/CMakeLists.txt
+ target_link_libraries(libB LINK_INTERFACE_LIBRARIES libA)\n
+ target_link_libraries(libC
[Cmake-commits] CMake branch, next, updated. v2.8.6-2018-g0799223
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 07992233965dc71ab03bfccc79179176996454b3 (commit)
via b1f12f8042ef0d7b190c04644905d3b3a325d4ae (commit)
via 5fc95dff464b08c83df2c904a281bb4c45278a35 (commit)
from 99966be1f7e2497bfca909db9232e64351687865 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07992233965dc71ab03bfccc79179176996454b3
commit 07992233965dc71ab03bfccc79179176996454b3
Merge: 99966be b1f12f8
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 22 17:26:35 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 22 17:26:35 2011 -0500
Merge topic 'target-link-libraries-interfaces' into next
b1f12f8 target_link_libraries: Simplify argument processing state tests
5fc95df target_link_libraries: Add missing space in documentation
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b1f12f8042ef0d7b190c04644905d3b3a325d4ae
commit b1f12f8042ef0d7b190c04644905d3b3a325d4ae
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 22 17:20:23 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Nov 22 17:21:36 2011 -0500
target_link_libraries: Simplify argument processing state tests
Remove extra parens in test for not handling LINK_INTERFACE_LIBRARIES.
Remove redundant test for equality with ProcessingPrivateInterface
subsumed by test for inequality with ProcessingPublicInterface.
diff --git a/Source/cmTargetLinkLibrariesCommand.cxx
b/Source/cmTargetLinkLibrariesCommand.cxx
index 0db5943..36c4ca8 100644
--- a/Source/cmTargetLinkLibrariesCommand.cxx
+++ b/Source/cmTargetLinkLibrariesCommand.cxx
@@ -217,8 +217,8 @@ bool cmTargetLinkLibrariesCommand
// Use of any of the new keywords implies awareness of
// this property. And if no libraries are named, it should
// result in an empty link interface.
- if((this-CurrentProcessingState != ProcessingLinkLibraries)
- !this-Target-GetProperty(LINK_INTERFACE_LIBRARIES))
+ if(this-CurrentProcessingState != ProcessingLinkLibraries
+ !this-Target-GetProperty(LINK_INTERFACE_LIBRARIES))
{
this-Target-SetProperty(LINK_INTERFACE_LIBRARIES, );
}
@@ -249,9 +249,9 @@ cmTargetLinkLibrariesCommand::HandleLibrary(const char* lib,
{
this-Makefile
-AddLinkLibraryForTarget(this-Target-GetName(), lib, llt);
-if (this-CurrentProcessingState != ProcessingPublicInterface
-|| this-CurrentProcessingState == ProcessingPrivateInterface)
+if (this-CurrentProcessingState != ProcessingPublicInterface)
{
+ // Not LINK_INTERFACE_LIBRARIES or LINK_PUBLIC, do not add to interface.
return;
}
}
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fc95dff464b08c83df2c904a281bb4c45278a35
commit 5fc95dff464b08c83df2c904a281bb4c45278a35
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 22 17:19:04 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Nov 22 17:19:04 2011 -0500
target_link_libraries: Add missing space in documentation
Change thelink to the link.
diff --git a/Source/cmTargetLinkLibrariesCommand.h
b/Source/cmTargetLinkLibrariesCommand.h
index e91c46d..8df4ac0 100644
--- a/Source/cmTargetLinkLibrariesCommand.h
+++ b/Source/cmTargetLinkLibrariesCommand.h
@@ -112,8 +112,8 @@ public:
[[debug|optimized|general] lib] ...\n
[LINK_PRIVATE|LINK_PUBLIC\n
[[debug|optimized|general] lib] ...])\n
- The LINK_PUBLIC and LINK_PRIVATE modes can be used to specify both the
- link dependencies and the link interface in one command.
+ The LINK_PUBLIC and LINK_PRIVATE modes can be used to specify both
+ the link dependencies and the link interface in one command.
Libraries and targets following LINK_PUBLIC are linked to, and are
made part of the LINK_INTERFACE_LIBRARIES. Libraries and targets
following LINK_PRIVATE are linked to, but are not made part of the
---
Summary of changes:
Source/cmTargetLinkLibrariesCommand.cxx |8
Source/cmTargetLinkLibrariesCommand.h |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
