[cmake-developers] [CMake 0012601]: CLang with Opiton -working-directory leads CMake to ommit fPIC in CXX_FLAGS for shared libs
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12601 == Reported By:doob Assigned To: == Project:CMake Issue ID: 12601 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-11-30 06:58 EST Last Modified: 2011-11-30 06:58 EST == Summary:CLang with Opiton -working-directory leads CMake to ommit fPIC in CXX_FLAGS for shared libs Description: I tried using CLang as drop in replacement for GCC with CMake and it worked just fine. (CLang Version 3.0) I just set CLang/CLang++ as the native C/CXX compiler in CMake. However since qtcreator didn't recognized the paths given by warning and error messages from CLang I forced CLang to output absolute paths always by setting -working-directory / to output paths relative to the root directory. However this seams to fool some internal setup/path detection or whatever process of CMake. If I use CLang together with -working-directory / I can't build shared libraries anymore, because CMake somehow fails on setting the proper fPIC flags then. Steps to Reproduce: On a shared library target building project: - set clang/clang++ as the native C/CXX compiler in CMake - build the project --- everything should be fine --- grep -l -R fPIC . will show you that fPIC is actually in the compile line. Look into your ./**/flags.make files. - add -working-directory / to C/CXX flags in CMake - make rebuild_cache - build the project --- linker complains about missing fPIC on your object files with something like: relocation R_X86_64_32S against `.bss' can not be used when making a shared object --- grep -l -R fPIC . will show you that fPIC is missing in the compile line. Look into your ./**/flags.make files. == Issue History Date ModifiedUsername FieldChange == 2011-11-30 06:58 doob New Issue == -- 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] Generating imported library targets without the cmake executable
Brad King wrote: On 11/29/2011 8:40 PM, Stephen Kelly wrote: Alexander Neundorf wrote: Nevertheless, personally I would also provide the Qt5Core_LIBRARY variable, so if somebody wants to have a look what that variable currently actually is (would by the name if the imported target), he can do that, and then maybe do something with the target name. This is harder if there is only the plural version of the variables. I'd say those singular versions are not strictly necessary, but they don't hurt and can in some cases be useful. If it's a cached variable, someone could potentially redefine QtCore_LIBRARY Alex was proposing simply to provide the singular name as a variable but not to cache it. The only reason to cache a variable is when we're searching and need to let the user help out or override. In a Config.cmake file we know the answer. Ok, so you're saying the user should definitely not be able to override the value, so it shouldn't be cached. The remaining question is whether it should be provided anyway uncached for the reasons Alex described. If that should be done, then I can do that. 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] Generating imported library targets without the cmake executable
On 11/30/2011 9:09 AM, Stephen Kelly wrote: Brad King wrote: Alex was proposing simply to provide the singular name as a variable but not to cache it. The only reason to cache a variable is when we're searching and need to let the user help out or override. In a Config.cmake file we know the answer. Ok, so you're saying the user should definitely not be able to override the value, so it shouldn't be cached. The remaining question is whether it should be provided anyway uncached for the reasons Alex described. If that should be done, then I can do that. I don't mind providing it for convenience. However more variables means more variables. Users may not know which one to use when. I don't have a strong opinion either way. -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] Generating imported library targets without the cmake executable
On Wednesday, November 30, 2011 07:33:48 am Stephen Kelly wrote: Brad King wrote: On 11/30/2011 9:09 AM, Stephen Kelly wrote: Brad King wrote: Alex was proposing simply to provide the singular name as a variable but not to cache it. The only reason to cache a variable is when we're searching and need to let the user help out or override. In a Config.cmake file we know the answer. Ok, so you're saying the user should definitely not be able to override the value, so it shouldn't be cached. The remaining question is whether it should be provided anyway uncached for the reasons Alex described. If that should be done, then I can do that. I don't mind providing it for convenience. However more variables means more variables. Users may not know which one to use when. I don't have a strong opinion either way. Ok, my opinion is to provide one variable in plural form for now. If there is a reason to provide a singular form, we can add that later. Let's just see what Alex and CLinton say before I do that. I have the same opinion -- only providing the plural form, at least for now. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating imported library targets without the cmake executable
On Wednesday 30 November 2011, Stephen Kelly wrote: Brad King wrote: On 11/30/2011 9:09 AM, Stephen Kelly wrote: Brad King wrote: Alex was proposing simply to provide the singular name as a variable but not to cache it. The only reason to cache a variable is when we're searching and need to let the user help out or override. In a Config.cmake file we know the answer. Ok, so you're saying the user should definitely not be able to override the value, so it shouldn't be cached. The remaining question is whether it should be provided anyway uncached for the reasons Alex described. If that should be done, then I can do that. I don't mind providing it for convenience. However more variables means more variables. Users may not know which one to use when. I don't have a strong opinion either way. Ok, my opinion is to provide one variable in plural form for now. If there is a reason to provide a singular form, we can add that later. Let's just see what Alex and CLinton say before I do that. I'd provide also the singular forms, but I don't have a strong opinion on it. 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] Generating imported library targets without the cmake executable
On Wednesday 30 November 2011, Stephen Kelly wrote: Alexander Neundorf wrote: On Tuesday 29 November 2011, Stephen Kelly wrote: Alexander Neundorf wrote: I can't generate the files. I'm asking people with windows and mac setups to generate them and post them for review. I don't have those setups. Just the ones for Linux would already help :-) I managed to get generated files for windows and mac through some IRC puppeteering, so I've attached them here now. Thanks, I looked through the QtCore files. Some things: if (NOT _Qt5Core_target) set(_Qt5Core_target 1) add_library(Qt5Core SHARED IMPORTED) if (NOT STREQUAL ) set_property(TARGET Qt5Core PROPERTY FRAMEWORK 1) endif() endif() I think you can simply do: if(NOT TARGET Qt5Core) add_library(Qt5Core SHARED IMPORTED) if (NOT STREQUAL ) set_property(TARGET Qt5Core PROPERTY FRAMEWORK 1) endif() endif() I didn't do it like this because that could potentially hide errors as described here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2147/focus =2152 Someone else could define a target called QtCore (in theory at least), and it makes sense to show a failure as early as possible. Hmm, ok. Somebody could also have set that variable already... ;-) For Qt4 I have put the imported targets into a namespace Qt4::, so they are e.g. Qt4::QtCore. It looks nice and it makes somewhat clear that Qt5Core is not the name of an in-project target, or the name of a library to link against, but something special (an imported target). I'd do that here too, so it would be Qt5::Qt5Core etc. This also reduces the risk of name clashes even more. Can this also handle already static builds of Qt ? Nope, not yet. Static builds of Qt are no longer tested by Nokia at least as far as I know. I don't know if it is even possible to build Qt statically on all (or any) platforms anymore. Ah, ok. So if we (at work) would like to have static builds, we maybe should take action ? 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] target_include_directories branch in stage
On Wednesday 30 November 2011, Brad King wrote: On 11/29/2011 2:28 PM, Alexander Neundorf wrote: ...a somewhat related idea: if it will be possible to set include directories per target, and since it is already possible to set compile flags per target, it would be nice if I could also set a property on targets which keeps them from using the global settings at all. The design for the new INCLUDE_DIRECTORIES property allows this. After the last include_directories() call in a directory one may set the INCLUDE_DIRECTORIES property of any target to anything and overwrite whatever came from the directory. Cool :-) In the current design the property is initialized when the target is created to the current directory-level value. Then each additional include_directories() call appends to the dir-level value *and* the targets in the directory. Perhaps the latter could be disabled by a property like you propose. Especially I'd be interested in having that for the compile flags. I'm not sure whether a disable all global or directory level settings would be enough or whether it should be fine-grained so that e.g. compile flags and include dirs could be disabled separately. Probably also link_directories() and link_libraries() (but they are more rarely used). 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 Wednesday 30 November 2011, Stephen Kelly wrote: Alexander Neundorf wrote: On Tuesday 22 November 2011, Stephen Kelly wrote: 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.c pp: 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.c pp:55:22: error: invalid use of incomplete type 'struct KDBusInterProcessLockPrivate' /home/stephen/dev/build/qt48/kf5/tier1/libkdbus/../../../../../src/kf5/tie r1/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. Please give the current AutomocIncludedDotMocFileHandling branch a try, it checks now also for this. Building solid still fails with the AutomocIncludedDotMocFileHandling branch. One of the reasons for failure is including a file with a different basename .moc. Fixed in solid with -#include devicenotifier.moc +#include moc_devicenotifier.cpp in devicemanager.cpp. The other failure is building files in subdirectories from a CMakeLists two levels up (all the files in the subdirectories are compiled into a single library) and including their moc files, which fails. /home/stephen/dev/src/kf5/tier1/solid/solid/backends/fakehw/fakedevice.cpp: 338:42: fatal error: backends/fakehw/fakedevice.moc: No such file or directory Solid builds standalone with Qt 4 in the frameworks branch. You already have it in your kdelibs git repo. The easiest thing would be: git new-workdir kdelibs kdelibs-frameworks frameworks cd kdelibs-frameworks/tier1/solid mkdir build cd build cmake .. make For convenience I put the current solid source here: http://www.steveire.com/share/solid.tar.gz Thanks. diff --git a/tier1/solid/solid/audiointerface.cpp b/tier1/solid/solid/audiointerface.cpp index ddf6cbc..98e42b2 100644 --- a/tier1/solid/solid/audiointerface.cpp +++ b/tier1/solid/solid/audiointerface.cpp @@ -67,4 +67,4 @@ Solid::AudioInterface::SoundcardType Solid::AudioInterface::soundcardType() cons return_SOLID_CALL(Ifaces::AudioInterface *, d-backendObject(), InternalSoundcard, soundcardType()); } -#include audiointerface.moc +#include moc_audiointerface.cpp An alternative way to fix this is to include QVariant in the header and not include the moc file here at all. - diff --git a/tier1/solid/solid/backends/fakehw/fakedevice.cpp b/tier1/solid/solid/backends/fakehw/fakedevice.cpp index dce82e4..1e5781a 100644 --- a/tier1/solid/solid/backends/fakehw/fakedevice.cpp +++ b/tier1/solid/solid/backends/fakehw/fakedevice.cpp @@ -335,5 +335,5 @@ QObject *FakeDevice::createDeviceInterface(const Solid::DeviceInterface::Type t return iface; } -#include backends/fakehw/fakedevice.moc +#include backends/fakehw/moc_fakedevice.cpp #include backends/fakehw/fakedevice_p.moc This one was actually a bug, this one works now with the updated branch. - diff --git a/tier1/solid/solid/devicemanager.cpp b/tier1/solid/solid/devicemanager.cpp index 06919c3..0fd8c89 100644 --- a/tier1/solid/solid/devicemanager.cpp +++ b/tier1/solid/solid/devicemanager.cpp @@ -288,6 +288,6 @@ void Solid::DeviceManagerStorage::ensureManagerCreated() } } -#include devicenotifier.moc +#include moc_devicenotifier.cpp #include moc_devicemanager_p.cpp In this case at least the error message is early and to the point: AUTOMOC: error: /home/alex/src/CMake/tests/solid/solid/devicemanager.cpp: The file includes the moc file devicenotifier.moc, which seems to be the moc file from a different source file. This is not supported. Include devicemanager.moc to run moc on this source file. An alternative fix is the following: diff -rbup solid.orig/solid//solid/CMakeLists.txt solid//solid/CMakeLists.txt ---
Re: [cmake-developers] cmake automoc breaks kde
Alexander Neundorf wrote: Thanks. diff --git a/tier1/solid/solid/audiointerface.cpp b/tier1/solid/solid/audiointerface.cpp index ddf6cbc..98e42b2 100644 --- a/tier1/solid/solid/audiointerface.cpp +++ b/tier1/solid/solid/audiointerface.cpp @@ -67,4 +67,4 @@ Solid::AudioInterface::SoundcardType Solid::AudioInterface::soundcardType() cons return_SOLID_CALL(Ifaces::AudioInterface *, d-backendObject(), InternalSoundcard, soundcardType()); } -#include audiointerface.moc +#include moc_audiointerface.cpp An alternative way to fix this is to include QVariant in the header and not include the moc file here at all. Personally I prefer fixing the moc include so that it's still possible to forward declare in the header file. It is very common to forward declare in KDE. I don't know how likely this is to occur though. However, including the correct include file is an easy fix. We can start the updating of the KDE moc strategy soon I think. You said that you can't detect this case, but why do you have to? Isn't there already a check for the Q_OBJECT macro in the cpp file? Wouldn't the logic be 'if the basename.moc file is included but there is no Q_OBJECT in the header, then moc the basename.h and put the result in basename.moc', or does that conflict with another rule? - diff --git a/tier1/solid/solid/backends/fakehw/fakedevice.cpp b/tier1/solid/solid/backends/fakehw/fakedevice.cpp index dce82e4..1e5781a 100644 --- a/tier1/solid/solid/backends/fakehw/fakedevice.cpp +++ b/tier1/solid/solid/backends/fakehw/fakedevice.cpp @@ -335,5 +335,5 @@ QObject *FakeDevice::createDeviceInterface(const Solid::DeviceInterface::Type t return iface; } -#include backends/fakehw/fakedevice.moc +#include backends/fakehw/moc_fakedevice.cpp #include backends/fakehw/fakedevice_p.moc This one was actually a bug, this one works now with the updated branch. Cool. - diff --git a/tier1/solid/solid/devicemanager.cpp b/tier1/solid/solid/devicemanager.cpp index 06919c3..0fd8c89 100644 --- a/tier1/solid/solid/devicemanager.cpp +++ b/tier1/solid/solid/devicemanager.cpp @@ -288,6 +288,6 @@ void Solid::DeviceManagerStorage::ensureManagerCreated() } } -#include devicenotifier.moc +#include moc_devicenotifier.cpp #include moc_devicemanager_p.cpp In this case at least the error message is early and to the point: AUTOMOC: error: /home/alex/src/CMake/tests/solid/solid/devicemanager.cpp: The file includes the moc file devicenotifier.moc, which seems to be the moc file from a different source file. This is not supported. Include devicemanager.moc to run moc on this source file. An alternative fix is the following: diff -rbup solid.orig/solid//solid/CMakeLists.txt solid//solid/CMakeLists.txt --- solid.orig/solid//solid/CMakeLists.txt 2011-11-23 11:32:15.0 +0100 +++ solid//solid/CMakeLists.txt 2011-11-30 21:48:13.0 +0100 @@ -42,6 +42,7 @@ set(solid_LIB_SRCS managerbase.cpp device.cpp devicemanager.cpp + devicenotifier.h deviceinterface.cpp genericinterface.cpp processor.cpp Seems out of place there. Again I prefer the direct include, but good that there's multiple solutions. diff -rbup solid.orig/solid//solid/devicemanager.cpp solid//solid/devicemanager.cpp --- solid.orig/solid//solid/devicemanager.cpp 2011-11-30 03:08:04.0 +0100 +++ solid//solid/devicemanager.cpp 2011-11-30 21:49:17.0 +0100 @@ -288,6 +288,5 @@ void Solid::DeviceManagerStorage::ensure } } -#include devicenotifier.moc #include moc_devicemanager_p.cpp You can decide how much of this should be covered in the backwards guarantee automoc feature and how much will require fixing solid instead. Yes, I'm quite undecided. The breakages above are caused by forward declarations in the header (which I can't detect), and by moc'ing files which are not known to cmake at all (devicenotifier.h, and there is no devicenotifier.cpp). So I think with the current cmQtAutomoc::ParseCpp() I can't handle and can't detect and warn for those cases. Which would mean that automoc in 2.8.7 will not be able to substitute the standalone automoc4 (as 2.8.6 was). This is not really good. But at least now in 2.8.7 automoc behaves more like what the documentation said already in 2.8.6, so it could be argued that everything which was working before is still working now and everything which does not work anymore was working only by accident. Which seems kind of ok, Yes, I think the situation is pretty good with it now, though we haven't tried to build the rest of KDE with it. but this still means that even if we start to require cmake 2.8.7 for kdelibs4, we still need the standalone automoc (which I don't feel like maintaining). Well, kdelibs4 is not really going to get any more releases. I'm not sure it makes sense to
Re: [cmake-developers] Generating imported library targets without the cmake executable
Stephen Kelly wrote: Brad King wrote: On 11/30/2011 9:09 AM, Stephen Kelly wrote: Brad King wrote: Alex was proposing simply to provide the singular name as a variable but not to cache it. The only reason to cache a variable is when we're searching and need to let the user help out or override. In a Config.cmake file we know the answer. Ok, so you're saying the user should definitely not be able to override the value, so it shouldn't be cached. The remaining question is whether it should be provided anyway uncached for the reasons Alex described. If that should be done, then I can do that. I don't mind providing it for convenience. However more variables means more variables. Users may not know which one to use when. I don't have a strong opinion either way. Ok, my opinion is to provide one variable in plural form for now. If there is a reason to provide a singular form, we can add that later. Let's just see what Alex and CLinton say before I do that. I've submitted patches now to remove unneeded variables, pluralize the remaining, and use Qt5::Core style for the targets. -- 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] Generating imported library targets without the cmake executable
Alexander Neundorf wrote: Static builds of Qt are no longer tested by Nokia at least as far as I know. I don't know if it is even possible to build Qt statically on all (or any) platforms anymore. Ah, ok. So if we (at work) would like to have static builds, we maybe should take action ? I would say now is a good time to see if you can build Qt the way you need to. Experimentally building your own project on top of the cmake stuff that is now in there should be possible. I've done it with grantlee and fixed a few bugs in Qt5 as a result, but I haven't tried any static builds. git clone git://gitorious.org/qt/qtbase.git -- 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
