[cmake-developers] [CMake 0013699]: Errors are not cleared when rebuilding a CMake-generated Eclipse CDT project
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13699
==
Reported By:vitaut
Assigned To:
==
Project:CMake
Issue ID: 13699
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-11-17 18:42 EST
Last Modified: 2012-11-17 18:42 EST
==
Summary:Errors are not cleared when rebuilding a
CMake-generated Eclipse CDT project
Description:
Some errors from previous builds are not cleared when rebuilding a
CMake-generated Eclipse CDT project. Most of the errors are cleared but the
following three persist in the Problems view:
make[1]: *** [CMakeFiles/test.dir/all] Error 2 C/C++
Problem
make: *** [all] Error 2 C/C++ Problem
make[2]: *** [CMakeFiles/test.dir/test.cc.o] Error 1
C/C++ Problem
These errors persist even if the project builds successfully which can be
checked by looking at the Console output.
I am using Eclipse CDT version 8.1.0.
Steps to Reproduce:
1. Create a simple C/C++ CMake project with a syntax error in the source code,
for example,
CMakeFiles.txt:
cmake_minimum_required(VERSION 2.6)
project(TEST)
add_executable(test test.cc)
test.cc:
int main() {
return 0 // missing semicolon
}
2. Generate Eclipse CDT project:
cmake -G "Eclipse CDT4 - Unix Makefiles"
3. Open the project in Eclipse and build it. The Problems view will contain the
following errors:
make[1]: *** [CMakeFiles/test.dir/all] Error 2 C/C++
Problem
make: *** [all] Error 2 C/C++ Problem
make[2]: *** [CMakeFiles/test.dir/test.cc.o] Error 1
C/C++ Problem
expected ‘;’ before ‘}’ token test.cc /TEST@test line 3 C/C++ Problem
4. Fix the error (add a semicolon after 0 in the example above), save the file
and build the project again. The Problems view will contain the following
errors:
make[1]: *** [CMakeFiles/test.dir/all] Error 2 C/C++
Problem
make: *** [all] Error 2 C/C++ Problem
make[2]: *** [CMakeFiles/test.dir/test.cc.o] Error 1
C/C++ Problem
Additional Information:
Changing the error parser from "CDT GNU Make Error Parser 6.0 (Deprecated)" to
"CDT GNU Make Error Parser 7.0" solves the problem but only until the project
file is generated again. The blog post http://www.jazzbee.com/blog/?p=76
suggests changing "org.eclipse.cdt.core.MakeErrorParser" to
"org.eclipse.cdt.core.GmakeErrorParser" in cmExtraEclipseCDT4Generator.cxx.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-11-17 18:42 vitaut 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] Specifying VS target platform
Hi,
On Tue, 18 Sep 2012 07:59:58 -0400, Brad King wrote:
On 09/18/2012 02:23 AM, Patrick Gansterer wrote:
If we store everything in one variable (via string concatenation) I
don't see much value in an extra -GP switch. We need to split the
${CMAKE_GENERATOR} variable into generator+platform then all the
time
anyway.
Maybe we can only change to current exact match of the generator
name
to a "startsWith" and let the global generator class decide if the
generator name is valid?
Yes, something like that in cmake::CreateGlobalGenerator will work.
It will be nice to get rid of the platform-varied generator classes.
The reference documentation we generate explicitly lists all names
with the platforms right now. That will have to be refactored to
list the platformless names with a note about where to specify the
platform name. Then we need a per-generator list of platform names
along with a note that one specifies "Win32" by leaving the platform
name off.
I found some time to work on this again. I only refectored the cmake in
a first step. If the commits at
https://gitorious.org/~paroga/cmake/parogas-cmake/commits/factory or a
similar solution gets merged, I'll refector the Visual Studio Generators
and then add support for the WinCE platform.
-- Patrick
--
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
[cmake-developers] General Config.cmake file issue on ArchLinux
Hi, maybe I am missing something, but here we go: on 64bit ArchLinux installations, /lib64/ is a symlink to /usr/lib/. /bin/ and /usr/bin/ are normal directories, no symlinks. Now if a Config.cmake files is installed into /usr/lib/foo/, and references other files of its installations using relative paths from its own location to e.g. /usr/bin/ (../../bin/ ), there is breakage. CMake finds FooConfig.cmake in /lib64/foo/FooConfig.cmake (which it seems to search before /usr/lib). Then it goes ../../bin/, but doesn't end up in /usr/bin/, where e.g. some executable is located, but instead it goes to /lib64/foo/../../bin/, which is /bin/, but the expected executable is not there, and so the FooConfig.cmake file fails. I'm not sure what the right way to deal with this is. Is this only on ArchLinux ? If so, maybe the best thing to do is to tell the ArchLinux developers to set up their symlinks in a different way ? Having e.g. /usr/lib64/ point to /usr/lib/ would make it work I think. Or if /lib64/ points to /usr/lib/, then maybe /bin/ should also point to /usr/bin/. Other ideas ? Or can CMake be tweaked to handle this ? 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] Correct way to get include directories for a target (automoc regression) ?
On Sunday 11 November 2012, Stephen Kelly wrote: > Alexander Neundorf wrote: > > On Sunday 11 November 2012, Stephen Kelly wrote: > >> Alexander Neundorf wrote: > >> > In 2.8.9 automoc did not ask the target for its include dirs, but it > >> > asked the directory for its include dirs. This contained and still > >> > contains as it seems the CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES. > >> > In 2.8.10 the target is asked for its include dirs, and it seems there > >> > the implicit include dirs have been stripped. > >> > >> It seems that the bug is in KDE/Phonon. Why do they populate the > >> CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES instead of the > >> INCLUDE_DIRECTORIES directory property? > >> > >> The patch that you added looks like a hack to me which is only for the > >> benefit of what KDE/Phonon is doing (but maybe shouldn't be). I'd prefer > >> to fix KDE/Phonon instead. > > > > It still is a backward compatibility break in cmake, for kdelibs, which > > is a big user of cmake. > > Are you sure? This only affects the CMAKE_AUTOMOC feature, which kdelibs > doesn't use. This seems to affect only phonon because they have started to > use CMAKE_AUTOMOC instead of automoc4, and because they have a copy of a > kdelibs macro. kdelibs should not be affected. KDE Frameworks 5 won't use > this trick to populate the implicit include directories, so it is only > phonon that is affected, as far as I can tell. > > Already this feature doesn't work with CMake 2.8.10 and phonon releases > since they started to use CMAKE_AUTOMOC. If we patch kdelibs and phonon now > to populate INCLUDE_DIRECTORIES instead of the internal system include > directories (or some other appropriate fix), then the next phonon release > will work with CMake 2.8.10 (right?) instead of having to wait for CMake > 2.8.11. It might be appropriate to patch both cmake and kdelibs/phonon so > that implicit directories are not appended to anymore. > > Do you know any reason not to do that? > > In fact, it was suggested to remove the macro in question earlier this > year: > > http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/5581/focus=7096 > > when an older thread from 2010 was revived. > > In that thread, appending to the implicit include dirs was selected as the > solution instead of seeing if CMake could be patched. Two years later we > hit issues resulting from that choice. For me, that's an argument for > finding out what the right fix in the right place is. > > The reported bugs are side-effects of populating the implicit include > directories as was done in 2010. > > As Raphael notes in the post I linked to, the fix might be simply relying > on the user to set up their environment, because we can't re-order include > directories for every /opt directory that someone might install to, while > they have system includes somewhere else. > > Your patch in FixAutomocRegression might result in inflexibility or bugs in > two years, so I think caution is in order. It might be the only way to re- > add 'backward compatibility' while not patching phonon at all (assuming > that is the goal), I don't know. I think it's worth considering Raphaels > post above, particularly: > > 'if, say, X11 and Soprano are installed into /opt/custom-prefix, the > original problem will show up again' > > Is making /usr/local an implicit include directory on freebsd the right > fix? I don't know, maybe. > > Does moc know actually know about system include dirs ? > > I don't know. Interestingly, moc seems to fail on some systems if all system include dirs are given to it, see the Raphaels comment ( http://public.kitware.com/Bug/view.php?id=13667#c31553) > > If it doesn't, this is not a hack, but potentially necessary. > > I think that depends on how the users environment is set up. > > Here's what I understand about how the bug occurs: > > http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=a9465098c01ace9ea > d62c04674dc2f4a529962f5 > > says that /usr/lib/qt/include is usually in QT_INCLUDES, but not passed to > moc. > > The reason /usr/lib/qt/include is not passed to moc is that it is inserted > by phonon into the implicit include directories for the language, and > therefore filtered out by cmLocalGenerator::AddIncludeDirectories. Yes. > The reason /usr/lib/qt/include is inserted by phonon into the implicit > include directories is that querying g++ returns that path. Is it normal > for g++ to return that (Qt specific) path as a system include, or is that > resulting from a patch the distros make to g++ based on where they install > Qt? At least it's also the case on my Slackware 13.37, and I think I didn't manually change this. ...this could have the interesting effect that I also get /usr/lib/qt/include when using some other Qt installation :-/ > The phonon and tomahawk related bug reports you linked to seem to be from > people who are using a distro-provided Qt, and FindQt4 finds it > appropriately, but phonon causes CMake to
