Re: [cmake-developers] cmake automoc breaks kde
On Monday 31 October 2011, David Faure wrote:
Hi Alex,
The latest changes in cmake-git (probably the merge of
AutomocFindQ_OBJECTAlwaysInHeader) break the compilation of kde-frameworks.
This is for fixing http://public.kitware.com/Bug/view.php?id=12533
Before:
Generating kauthactionwatcher.moc
AUTOMOC: Checking kauthactionwatcher.cpp
moc [...] -o kauthactionwatcher.moc kauthactionwatcher.h
After:
AUTOMOC: Checking kauthactionwatcher.h
AUTOMOC: Checking kauthactionwatcher.cpp
Generating moc_kauthactionwatcher.cpp
moc [...] moc_kauthactionwatcher.cpp kauthactionwatcher.h
leading to
Error: moc_kauthactionwatcher.cpp:75:22: error: invalid use of incomplete
type 'struct KAuth::ActionWatcher::Private'
Generating kauthactionwatcher.moc
moc [...] -o kauthactionwatcher.moc kauthactionwatcher.cpp
kauthactionwatcher.cpp:0: Note: No relevant classes found. No output
generated.
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 ?
Is this really a typical case, i.e. is that done in many places ?
I thought the rule is that if there is a include foo.moc, the Q_OBJECT is in
the same cpp file.
That's also what is documented for cmake 2.8.6.
If it did additionally other things, this was more or less accidentially.
Apparently it now creates two moc files, one for the .cpp file (empty) and
Yes, because kauthactionwatcher.moc is included.
one for the .h file (but with the wrong name, so not included during
compilation).
Yes, because it contains a Q_OBJECT macro.
The logic which is currently implemented is:
1. if foo.cpp includes foo.moc, run moc on foo.cpp and generate foo.moc
2. run moc on all header files bar.h which contain Q_OBJECT and generate
moc_bar.cpp from them
(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 in targetname_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.
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 ?
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] Building a main.cpp containing a QObject subclass
On 31.10.11 12:15:23, Laszlo Papp wrote: Hi, I would like to achieve something like this by using cmake: http://doc.qt.nokia.com/4.8/activeqt-comapp.html I would like to have a QObject subclass in my main.cpp file since it has just one method for instance, and thus it would be a convenient approach for me. Three problems in your example: a) for qt4_automoc (and presumambly the cmake-builtin moc-support) you need to use the #include moc_XXX... form when the QObject class is in a C++ implementation file. The #include XXX.moc version is for the cases where the header contains the qobject class. b) The FindQt4.cmake file developers decided to use .cxx as C++ file extension, probably to avoid conflicts with existing files. So the above needs to read #include moc_XXX.cxx for qt4_automoc to work c) Your class declaration lacks the semicolon at its end. With all those fixed the sample should compile. 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] Building a main.cpp containing a QObject subclass
Thank you for your help Andreas. I have tried your approach. Please
see the attached logs. The moc files are now somehow not generated. I
might need to use qt4_wrap_cpp after all ?
Best Regards,
Laszlo Papp
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/colorgcc
-- Check for working C compiler: /usr/bin/colorgcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found.
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found.
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found.
-- Found Qt4: /usr/bin/qmake (found version 4.7.4)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/lpapp/Projects/kde/test/build
/usr/bin/cmake -H/home/lpapp/Projects/kde/test -B/home/lpapp/Projects/kde/test/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/lpapp/Projects/kde/test/build/CMakeFiles /home/lpapp/Projects/kde/test/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/lpapp/Projects/kde/test/build'
make -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/depend
make[2]: Entering directory `/home/lpapp/Projects/kde/test/build'
cd /home/lpapp/Projects/kde/test/build /usr/bin/cmake -E cmake_depends Unix Makefiles /home/lpapp/Projects/kde/test /home/lpapp/Projects/kde/test /home/lpapp/Projects/kde/test/build /home/lpapp/Projects/kde/test/build /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/DependInfo.cmake --color=
Dependee /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/DependInfo.cmake is newer than depender /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/depend.internal.
Dependee /home/lpapp/Projects/kde/test/build/CMakeFiles/CMakeDirectoryInformation.cmake is newer than depender /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/depend.internal.
Scanning dependencies of target test
make[2]: Leaving directory `/home/lpapp/Projects/kde/test/build'
make -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/build
make[2]: Entering directory `/home/lpapp/Projects/kde/test/build'
/usr/bin/cmake -E cmake_progress_report /home/lpapp/Projects/kde/test/build/CMakeFiles 1
[100%] Building CXX object CMakeFiles/test.dir/main.cpp.o
/usr/lib/colorgcc/bin/c++-g -I/home/lpapp/Projects/kde/test -I/home/lpapp/Projects/kde/test/build-o CMakeFiles/test.dir/main.cpp.o -c /home/lpapp/Projects/kde/test/main.cpp
/home/lpapp/Projects/kde/test/main.cpp:8:24: fatal error: moc_main.cpp: No such file or directory
compilation terminated.
make[2]: *** [CMakeFiles/test.dir/main.cpp.o] Error 1
make[2]: Leaving directory `/home/lpapp/Projects/kde/test/build'
make[1]: *** [CMakeFiles/test.dir/all] Error 2
make[1]: Leaving directory `/home/lpapp/Projects/kde/test/build'
make: *** [all] Error 2
root /home/lpapp/Projects/kde/test/build # cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
find_package(Qt4)
set(test_SRCS
main.cpp
)
qt4_automoc(${test_SRCS})
add_executable(test ${test_SRCS})
root /home/lpapp/Projects/kde/test/build # cat ../main.cpp
#include QtCore/QObject
class MyClass : public QObject
{
Q_OBJECT
};
#include moc_main.cpp
int main( int argc, char** argv )
{
return 0;
}
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/colorgcc
-- Check for working C compiler: /usr/bin/colorgcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found.
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found.
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found.
-- Found Qt4: /usr/bin/qmake (found version 4.7.4)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/lpapp/Projects/kde/test/build
/usr/bin/cmake -H/home/lpapp/Projects/kde/test -B/home/lpapp/Projects/kde/test/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/lpapp/Projects/kde/test/build/CMakeFiles /home/lpapp/Projects/kde/test/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/lpapp/Projects/kde/test/build'
make -f CMakeFiles/test.dir/build.make
Re: [CMake] Building a main.cpp containing a QObject subclass
On 31.10.11 13:10:28, Laszlo Papp wrote: Thank you for your help Andreas. I have tried your approach. Please see the attached logs. The moc files are now somehow not generated. I might need to use qt4_wrap_cpp after all ? Sorry, seems like my local experiments led to wrong conclusions here. At least CMake 2.8.5-rc2 ships with a Qt4Macros.cmake file in which QT4_AUTOMOC can only QObject subclasses in header files (i.e. the foo.moc form). Don't know about the cmake-builtin automoc support since I don't have 2.8.6 at hand here. So yes, at least with the macro's you'll have to go with qt4_wrap_cpp or write your own automoc macro, which shouldn't be too hard if you look at the existing one. 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] Building a main.cpp containing a QObject subclass
I am now attaching the log about the following files:
1) CMakeLists.txt file
2) main.cpp
3) build log
4) moc_main.cxx
Q_MOC_OUTPUT_REVISION is somehow not defined, but not sure why.
Best Regards,
Laszlo Papp
On Mon, Oct 31, 2011 at 1:31 PM, Andreas Pakulat ap...@gmx.de wrote:
On 31.10.11 13:10:28, Laszlo Papp wrote:
Thank you for your help Andreas. I have tried your approach. Please
see the attached logs. The moc files are now somehow not generated. I
might need to use qt4_wrap_cpp after all ?
Sorry, seems like my local experiments led to wrong conclusions here. At
least CMake 2.8.5-rc2 ships with a Qt4Macros.cmake file in which
QT4_AUTOMOC can only QObject subclasses in header files (i.e. the
foo.moc form). Don't know about the cmake-builtin automoc support since
I don't have 2.8.6 at hand here.
So yes, at least with the macro's you'll have to go with qt4_wrap_cpp or
write your own automoc macro, which shouldn't be too hard if you look at
the existing one.
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
cmake_minimum_required(VERSION 2.8)
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
find_package(Qt4)
include_directories(
${QT_INCLUDES}
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
)
set(test_SRCS
main.cpp
)
qt4_wrap_cpp(test_MOC_FILES ${test_SRCS})
#qt4_automoc(${test_SRCS})
add_executable(test ${test_SRCS} ${test_MOC_FILES})
target_link_libraries(test ${QT_QTCORE_LIBRARY})
#include QtCore/QObject
class MyClass : public QObject
{
Q_OBJECT
};
#include moc_main.cxx
int main( int argc, char** argv )
{
return 0;
}
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/colorgcc
-- Check for working C compiler: /usr/bin/colorgcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found.
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found.
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found.
-- Found Qt4: /usr/bin/qmake (found version 4.7.4)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/lpapp/Projects/kde/test/build
/usr/bin/cmake -H/home/lpapp/Projects/kde/test -B/home/lpapp/Projects/kde/test/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/lpapp/Projects/kde/test/build/CMakeFiles /home/lpapp/Projects/kde/test/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/lpapp/Projects/kde/test/build'
make -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/depend
make[2]: Entering directory `/home/lpapp/Projects/kde/test/build'
/usr/bin/cmake -E cmake_progress_report /home/lpapp/Projects/kde/test/build/CMakeFiles 3
[ 33%] Generating moc_main.cxx
/usr/bin/moc -I/home/lpapp/Projects/kde/test -I/home/lpapp/Projects/kde/test/build -I/usr/include/QtDesigner -I/usr/include/QtDeclarative -I/usr/include/QtScriptTools -I/usr/include/QtDBus -I/usr/include/QtXml -I/usr/include/QtSql -I/usr/include/QtOpenGL -I/usr/include/QtMultimedia -I/usr/include/QtNetwork -I/usr/include/phonon -I/usr/include/QtXmlPatterns -I/usr/include/QtWebKit -I/usr/include/QtHelp -I/usr/include/QtUiTools -I/usr/include/QtTest -I/usr/include/QtScript -I/usr/include/QtSvg -I/usr/include/Qt3Support -I/usr/include/QtGui -I/usr/include/QtCore -I/usr/share/qt/mkspecs/default -I/usr/include -o /home/lpapp/Projects/kde/test/build/moc_main.cxx /home/lpapp/Projects/kde/test/main.cpp
cd /home/lpapp/Projects/kde/test/build /usr/bin/cmake -E cmake_depends Unix Makefiles /home/lpapp/Projects/kde/test /home/lpapp/Projects/kde/test /home/lpapp/Projects/kde/test/build /home/lpapp/Projects/kde/test/build /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/DependInfo.cmake --color=
Dependee /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/DependInfo.cmake is newer than depender /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/depend.internal.
Dependee /home/lpapp/Projects/kde/test/build/CMakeFiles/CMakeDirectoryInformation.cmake is newer than depender /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/depend.internal.
Scanning dependencies of target test
make[2]: Leaving directory `/home/lpapp/Projects/kde/test/build'
make -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/build
make[2]: Entering directory
Re: [CMake] Building a main.cpp containing a QObject subclass
On 31.10.11 14:47:07, Laszlo Papp wrote: I am now attaching the log about the following files: 1) CMakeLists.txt file 2) main.cpp 3) build log 4) moc_main.cxx Q_MOC_OUTPUT_REVISION is somehow not defined, but not sure why. You're not supposed to add the mocfiles variable contents you receive from qt4_wrap_cpp to the list of sources. In particular not because you already #include that same file in the main.cpp. If you look at the generated file you'll notice that it requires all the declarations from the main.cpp, i.e. its not a standalone C++ source and cannot be compiled on its own. 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] Building a main.cpp containing a QObject subclass
You're not supposed to add the mocfiles variable contents you receive
from qt4_wrap_cpp to the list of sources. In particular not because you
already #include that same file in the main.cpp. If you look at the
generated file you'll notice that it requires all the declarations from
the main.cpp, i.e. its not a standalone C++ source and cannot be
compiled on its own.
You are right. That sounds logical. Unfortunately, the moc file is not
generated if I do it that way. If I generate it manually, the build
works. Is there a way, similar to add_dependencies, to tell moc in the
CMakeLists.txt file to generate the moc_main.cxx before the main.cpp ?
I think those macros are not enough alone since
qt4_generate_moc(main.cpp moc_main.cxx) did not work either. I would
expect that qt4_generate_moc can work for source files. Apparently,
qt4_wrap_cpp can work only for header files ...
Something like this might work by using automoc, but is this really
that hard by using cmake ? Please do not take it an offense, but it is
pretty simple by using qmake ;)
[code]
cmake_minimum_required(VERSION 2.8)
find_package(Automoc4 REQUIRED)
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
find_package(Qt4)
include_directories(
${QT_INCLUDES}
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
)
set(test_SRCS
main.cpp
)
automoc4_add_executable(test ${test_SRCS})
target_link_libraries(test ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY})
[/code]
Also,set(CMAKE_AUTOMOC ON) aborts the build:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct null not valid
Aborted
I have cmake version 2.8.6. installed.
Best Regards,
Laszlo Papp
--
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 still broken post-2.8.1
2011/10/27 Phil Smith p...@voltage.com: Ok, tried the CMakeLists change, no change. The Dignus-related files are attached. Thanks, nothing strange in there. Sorry for the delay, but I'm entering a not so much spare time loop moreover I should admit I do not have any more debugging idea for your problem. Since I may not be able to reproduce your problem I'm stuck. I hope someone here could take over and help you more. If ever you would be able to reproduce the problem with some publicly available tools it would be easier to seek the issue. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] Building a main.cpp containing a QObject subclass
Okay: I got it working by using qt4_generate_moc :) I am not sure it
is the cleanest way. Fixing the set(CMAKE_AUTOMOC ON) abort will
probably the cleanest.. Thank you for your help again! :)
Best Regards,
Laszlo Papp
cmake_minimum_required(VERSION 2.8)
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
find_package(Qt4)
include_directories(
${QT_INCLUDES}
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
)
qt4_generate_moc(main.cpp ${CMAKE_CURRENT_BINARY_DIR}/main.moc)
set(test_SRCS
main.cpp
main.moc
)
add_executable(test ${test_SRCS})
target_link_libraries(test ${QT_QTCORE_LIBRARY})
--
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] Building a main.cpp containing a QObject subclass
On 31.10.11 15:38:52, Laszlo Papp wrote: You're not supposed to add the mocfiles variable contents you receive from qt4_wrap_cpp to the list of sources. In particular not because you already #include that same file in the main.cpp. If you look at the generated file you'll notice that it requires all the declarations from the main.cpp, i.e. its not a standalone C++ source and cannot be compiled on its own. You are right. That sounds logical. Unfortunately, the moc file is not generated if I do it that way. If I generate it manually, the build works. Is there a way, similar to add_dependencies, to tell moc in the CMakeLists.txt file to generate the moc_main.cxx before the main.cpp ? Yes, add_custom_target can be used: add_custom_target( foo DEPENDS mocfiles ); add_dependencies( exe foo ); I think those macros are not enough alone since qt4_generate_moc(main.cpp moc_main.cxx) did not work either. I would expect that qt4_generate_moc can work for source files. Apparently, qt4_wrap_cpp can work only for header files ... No, its just the missing dependency. Something like this might work by using automoc, but is this really that hard by using cmake ? Its not, but someone has to do it. As I said I don't know how the automoc in cmake 2.8.6 behaves. What I do know is that KDE's automoc does support all this with 2 macros (a pre-target and a post-target one), but it requires a separate C++ app. Please do not take it an offense, but it is pretty simple by using qmake ;) Yes, but qmake can build Qt projects for quite some more time than CMake can ;) Also,set(CMAKE_AUTOMOC ON) aborts the build: terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_S_construct null not valid Aborted That looks like a cmake bug that should be reported. 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] Source control bindings feature in CMake needs better documentation
While waiting on a response I did some experimentation:
set_target_properties(
${project_name} PROPERTIES
VS_SCC_LOCALPATH ${CMAKE_SOURCE_DIR}
VS_SCC_PROJECTNAME Perforce Project
VS_SCC_PROVIDER MSSCCI:Perforce SCM
)
This seems to work in VS 2003 but the annoying thing is that when I open
the solution, every single project (about 120 of them) each prompt me for
my username, workspace, and server URL to perforce server.
Is there no way to specify this connection/user/workspace information in
CMake so that when I open the solution it already knows this stuff?
-
Robert Dailey
On Mon, Oct 31, 2011 at 12:24 PM, Robert Dailey rcdai...@gmail.com wrote:
Hey guys,
Our team is running Perforce here at work and I want to setup any Visual
Studio projects generated to use source control bindings for Perforce.
The documentation for VS_SCC_PROJECTNAME, VS_SCC_LOCALPATH,
VS_SCC_PROVIDER is pretty bad and I really have no clue on how to use
these. Could someone explain what each is and possibly provide some
examples on how they are used for Perforce?
Thanks!!
-
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
Re: [CMake] How to link against libraries in subdirectory (windows workaround)
On Saturday 29 October 2011, Renato Utsch wrote:
Hello!
Well, I am currently using cURL for a project of mine, but on windows I
can't find the cURL library only using the find_package(CURL) provided with
CMake, although it works fine with linux.
So, I created a directory named deps in my source directory. How can I
make the find_package to look at this directory before looking at the
default directories? Like:
# Look firstly at the /deps directory, if finds the libcurl.a and the
include/curl folder set the CURL_FOUND macro and the other ones that the
find_package() automatically provides...
You can set CMAKE_PREFIX_PATH so that it looks first in that subdir and then
in the default dirs:
set(CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH} ${CMAKE_SOURCE_DIR}/deps/ )
find_package(curl)
...etc.
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestions on documenting my CMake modules
On Saturday 29 October 2011, Robert Dailey wrote: I have several complex functions which require a ton of documentation. I wanted to type this documentation directly in the cmake file right above the function() itself, but it is turning out to be a formatting nightmare. What would you guys recommend as far as this kind of documentation goes? It would be great if doxygen could scan CMake scripts and generate HTML documentation out of them, but I don't know if this is possible. Also, typing up the documentation in a wiki externally would ease the formatting but would require people to go to an external source for documentation that would otherwise be immediately available in the code itself. A patch to add some more formatting options to the cmake docs would be welcome :-) Like e.g. *bold*, _italic_ and something for preformatted text. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a main.cpp containing a QObject subclass
On Monday 31 October 2011, Laszlo Papp wrote:
Hi,
I would like to achieve something like this by using cmake:
http://doc.qt.nokia.com/4.8/activeqt-comapp.html
I would like to have a QObject subclass in my main.cpp file since it
has just one method for instance, and thus it would be a convenient
approach for me.
This is my current CMakeLists.txt file:
[code]
cmake_minimum_required(VERSION 2.8)
include_directories(${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR})
find_package(Qt4)
#set(CMAKE_AUTOMOC ON)
set(test_SRCS
main.cpp
)
qt4_automoc(${test_SRCS})
I'd advice against using this.
Among others it only rechecks at cmake time, which is not enforced by simply
editing the source files.
The straightforward way should be
qt4_wrap_cpp(mocFiles main.cpp)
add_executable(test ${test_SRCS} ${mocFiles})
and then _not_ include the moc file in main.cpp.
add_executable(test ${test_SRCS})
[/code]
This is my current main.cpp file:
[code]
#include QtCore/QObject
class MyClass : public QObject
{
Q_OBJECT
}
#include main.moc
int main( int argc, char** argv )
{
return 0;
}
[/code]
This should work with CMAKE_AUTOMOC ON.
I'll check why it doesn't.
Another options is to use automoc4, which is what is used by KDE4 (wrapped in
KDE macros):
http://techbase.kde.org/Development/Tools/Automoc4
If you use master, its only dependency is QtCore, if you use the no-qt branch,
it needs only C++ and a STL (this is what has been integrated in cmake).
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a main.cpp containing a QObject subclass
On Monday 31 October 2011, Laszlo Papp wrote:
...
[code]
cmake_minimum_required(VERSION 2.8)
find_package(Automoc4 REQUIRED)
include_directories(${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR}) find_package(Qt4)
include_directories(
${QT_INCLUDES}
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
)
set(test_SRCS
main.cpp
)
automoc4_add_executable(test ${test_SRCS})
target_link_libraries(test ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY})
[/code]
Also,set(CMAKE_AUTOMOC ON) aborts the build:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct null not valid
Aborted
Please add a bug in the cmake bug tracker for that:
http://public.kitware.com/Bug/
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a main.cpp containing a QObject subclass
Please add a bug in the cmake bug tracker for that: http://public.kitware.com/Bug/ David Faure has fixed it today, and the patch is probably in your inbox somewhere. :P Best Regards, Laszlo Papp -- 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] Suggestions on documenting my CMake modules
Am Montag, 31. Oktober 2011, 20:58:45 schrieb Alexander Neundorf: On Saturday 29 October 2011, Robert Dailey wrote: I have several complex functions which require a ton of documentation. I wanted to type this documentation directly in the cmake file right above the function() itself, but it is turning out to be a formatting nightmare. What would you guys recommend as far as this kind of documentation goes? It would be great if doxygen could scan CMake scripts and generate HTML documentation out of them, but I don't know if this is possible. Also, typing up the documentation in a wiki externally would ease the formatting but would require people to go to an external source for documentation that would otherwise be immediately available in the code itself. A patch to add some more formatting options to the cmake docs would be welcome :-) Like e.g. *bold*, _italic_ and something for preformatted text. Just that your /italic/ was _underlined_. Eike signature.asc Description: This is a digitally signed message part. -- 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 2.8.5 qt4 macros and file names with parentheses
Short version: shouldn't the macros in Modules/Qt4Macros.cmake call
ADD_CUSTOM_COMMAND with VERBATIM?
Long version:
I'm trying to build
https://github.com/pflaquerre/torch/tree/build-under-path-with-parentheses
with cmake 2.8.5. It works fine when building in, say, /tmp/test/, but
not in /tmp/test(foo):
cd /tmp/test(foo)/build.rel/qtlua/qlua /usr/lib64/qt4/bin/rcc -name qlua
-o /tmp/test(foo)/build.rel/qtlua/qlua/qrc_qlua.cxx
/tmp/test(foo)/qtlua/qlua/qlua.qrc
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `cd /tmp/test(foo)/build.rel/qtlua/qlua
/usr/lib64/qt4/bin/rcc -name qlua -o
/tmp/test(foo)/build.rel/qtlua/qlua/qrc_qlua.cxx
/tmp/test(foo)/qtlua/qlua/qlua.qrc'
make[2]: *** [qtlua/qlua/qrc_qlua.cxx] Error 1
make[2]: Leaving directory `/tmp/test(foo)/build.rel'
make[1]: *** [qtlua/qlua/CMakeFiles/libqlua.dir/all] Error 2
make[1]: Leaving directory `/tmp/test(foo)/build.rel'
make: *** [all] Error 2
The issue is obviously the lack of quotes around the paths, but I'm
not sure what is causing it. One of the offending cmake files is
https://github.com/pflaquerre/torch/blob/build-under-path-with-parentheses/qtlua/qlua/CMakeLists.txt,
which calls MACRO_QT4_AUTOGEN from
https://github.com/pflaquerre/torch/blob/build-under-path-with-parentheses/qtlua/cmake/MacroQt4AutoGen.cmake,
which in turn calls the cmake macros QT4_WRAP_UI, QT4_ADD_RESOURCES,
QT4_WRAP_CPP and QT4_GENERATE_MOC. However, it doesn't seem like those
cmake files are doing anything wrong as far as quoting goes. I had a
look at the latest Modules/Qt4Macros.cmake on github and noticed that
there are a few places where ADD_CUSTOM_COMMAND is not called with
VERBATIM. For instance, QT4_CREATE_MOC_COMMAND only uses VERBATIM on
WIN32:
MACRO (QT4_CREATE_MOC_COMMAND infile outfile moc_flags moc_options)
# For Windows, create a parameters file to work around command line length
limit
IF (WIN32)
# Pass the parameters in a file. Set the working directory to
# be that containing the parameters file and reference it by
# just the file name. This is necessary because the moc tool on
# MinGW builds does not seem to handle spaces in the path to the
# file given with the @ syntax.
GET_FILENAME_COMPONENT(_moc_outfile_name ${outfile} NAME)
GET_FILENAME_COMPONENT(_moc_outfile_dir ${outfile} PATH)
IF(_moc_outfile_dir)
SET(_moc_working_dir WORKING_DIRECTORY ${_moc_outfile_dir})
ENDIF(_moc_outfile_dir)
SET (_moc_parameters_file ${outfile}_parameters)
SET (_moc_parameters ${moc_flags} ${moc_options} -o ${outfile}
${infile})
STRING (REPLACE ; \n _moc_parameters ${_moc_parameters})
FILE (WRITE ${_moc_parameters_file} ${_moc_parameters})
ADD_CUSTOM_COMMAND(OUTPUT ${outfile}
COMMAND ${QT_MOC_EXECUTABLE}
@${_moc_outfile_name}_parameters
DEPENDS ${infile}
${_moc_working_dir}
VERBATIM)
ELSE (WIN32)
ADD_CUSTOM_COMMAND(OUTPUT ${outfile}
COMMAND ${QT_MOC_EXECUTABLE}
ARGS ${moc_flags} ${moc_options} -o ${outfile} ${infile}
DEPENDS ${infile})
ENDIF (WIN32)
ENDMACRO (QT4_CREATE_MOC_COMMAND)
Is this on purpose? Adding VERBATIM to the ADD_CUSTOM_COMMAND calls in
that file solved the quoting issue and allowed me to build without any
problems. Is that project just misusing cmake, or is it really a
problem with Qt4Macros.cmake?
Regards,
Pierre-Francois
--
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] Blog series on Cross-Compiling from Windows for ARM Linux
On Friday 28 October 2011, Alistair Lowe wrote: Hi Guys, I just wished to let you know about a blog series I'm working on: http://blog.quickforge.co.uk/2011/10/exploration-of-cross-compiling-on-wind ows-for-arm-linux-distributions/ It details my experiences working with CMake, Boost, Wt and more whilst cross-compiling from Windows for ARM GNU Linux. I added a link here in the cmake wiki: http://www.vtk.org/Wiki/CMake#How_to_use_CMake_with_specific_Libraries 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://www.cmake.org/mailman/listinfo/cmake
[CMake] SCC bindings missing AUXPATH support?
There are actually 4 SCC related key/value pairs used in VS2003 VCPROJ files: SccProjectName=SAK SccAuxPath=SAK SccLocalPath=SAK SccProvider=SAK CMake supports these 3 via set_target_properties(): VS_SCC_LOCALPATH VS_SCC_PROJECTNAME VS_SCC_PROVIDER Apparently one more is needed to support SccAuxPath: VS_SCC_AUXPATH Can someone add support for this? Thanks. - 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
Re: [CMake] Building a main.cpp containing a QObject subclass
On Monday 31 October 2011, Laszlo Papp wrote: Please add a bug in the cmake bug tracker for that: http://public.kitware.com/Bug/ David Faure has fixed it today, and the patch is probably in your inbox somewhere. :P Haven't noticed anything. Beside that, I committed a fix to the DontCrashAutomocWithEmptyCompileDefs branch and merged it into next, so it should be in cmake master next week. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suggestions on documenting my CMake modules
On Monday 31 October 2011, Rolf Eike Beer wrote: Am Montag, 31. Oktober 2011, 20:58:45 schrieb Alexander Neundorf: On Saturday 29 October 2011, Robert Dailey wrote: I have several complex functions which require a ton of documentation. I wanted to type this documentation directly in the cmake file right above the function() itself, but it is turning out to be a formatting nightmare. What would you guys recommend as far as this kind of documentation goes? It would be great if doxygen could scan CMake scripts and generate HTML documentation out of them, but I don't know if this is possible. Also, typing up the documentation in a wiki externally would ease the formatting but would require people to go to an external source for documentation that would otherwise be immediately available in the code itself. A patch to add some more formatting options to the cmake docs would be welcome :-) Like e.g. *bold*, _italic_ and something for preformatted text. Just that your /italic/ was _underlined_. Also good :-) Different wikis do different things... 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a main.cpp containing a QObject subclass
On 31.10.11 21:07:45, Alexander Neundorf wrote:
On Monday 31 October 2011, Laszlo Papp wrote:
Hi,
I would like to achieve something like this by using cmake:
http://doc.qt.nokia.com/4.8/activeqt-comapp.html
I would like to have a QObject subclass in my main.cpp file since it
has just one method for instance, and thus it would be a convenient
approach for me.
This is my current CMakeLists.txt file:
[code]
cmake_minimum_required(VERSION 2.8)
include_directories(${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR})
find_package(Qt4)
#set(CMAKE_AUTOMOC ON)
set(test_SRCS
main.cpp
)
qt4_automoc(${test_SRCS})
I'd advice against using this.
Among others it only rechecks at cmake time, which is not enforced by simply
editing the source files.
The straightforward way should be
qt4_wrap_cpp(mocFiles main.cpp)
add_executable(test ${test_SRCS} ${mocFiles})
and then _not_ include the moc file in main.cpp.
As explained elsewhere in the thread, this does not work because the
file generated by moc for the classes in the .cpp file will not compile
standalone. It requires the declarations from the .cpp file, hence
#include'ing the moc-generated file is the only option. Adding it to the
executable as source is hence not going to work and that means one needs
to manually add dependencies to get cmake to generate it in the first
place.
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] cmake 2.8.5 qt4 macros and file names with parentheses
On Monday, October 31, 2011 02:39:16 pm Pierre-Francois Laquerre wrote:
Short version: shouldn't the macros in Modules/Qt4Macros.cmake call
ADD_CUSTOM_COMMAND with VERBATIM?
Yes, it looks like it should. Can you add a bug in the bug tracker?
Thanks,
Clint
Long version:
I'm trying to build
https://github.com/pflaquerre/torch/tree/build-under-path-with-parentheses
with cmake 2.8.5. It works fine when building in, say, /tmp/test/, but
not in /tmp/test(foo):
cd /tmp/test(foo)/build.rel/qtlua/qlua /usr/lib64/qt4/bin/rcc -name
qlua -o /tmp/test(foo)/build.rel/qtlua/qlua/qrc_qlua.cxx
/tmp/test(foo)/qtlua/qlua/qlua.qrc /bin/sh: -c: line 0: syntax error
near unexpected token `('
/bin/sh: -c: line 0: `cd /tmp/test(foo)/build.rel/qtlua/qlua
/usr/lib64/qt4/bin/rcc -name qlua -o
/tmp/test(foo)/build.rel/qtlua/qlua/qrc_qlua.cxx
/tmp/test(foo)/qtlua/qlua/qlua.qrc' make[2]: ***
[qtlua/qlua/qrc_qlua.cxx] Error 1
make[2]: Leaving directory `/tmp/test(foo)/build.rel'
make[1]: *** [qtlua/qlua/CMakeFiles/libqlua.dir/all] Error 2
make[1]: Leaving directory `/tmp/test(foo)/build.rel'
make: *** [all] Error 2
The issue is obviously the lack of quotes around the paths, but I'm
not sure what is causing it. One of the offending cmake files is
https://github.com/pflaquerre/torch/blob/build-under-path-with-parentheses/
qtlua/qlua/CMakeLists.txt, which calls MACRO_QT4_AUTOGEN from
https://github.com/pflaquerre/torch/blob/build-under-path-with-parentheses/
qtlua/cmake/MacroQt4AutoGen.cmake, which in turn calls the cmake macros
QT4_WRAP_UI, QT4_ADD_RESOURCES, QT4_WRAP_CPP and QT4_GENERATE_MOC.
However, it doesn't seem like those cmake files are doing anything wrong
as far as quoting goes. I had a look at the latest Modules/Qt4Macros.cmake
on github and noticed that there are a few places where
ADD_CUSTOM_COMMAND
is not called with VERBATIM. For instance, QT4_CREATE_MOC_COMMAND only
uses VERBATIM on
WIN32:
MACRO (QT4_CREATE_MOC_COMMAND infile outfile moc_flags moc_options)
# For Windows, create a parameters file to work around command line
length limit IF (WIN32)
# Pass the parameters in a file. Set the working directory to
# be that containing the parameters file and reference it by
# just the file name. This is necessary because the moc tool on
# MinGW builds does not seem to handle spaces in the path to the
# file given with the @ syntax.
GET_FILENAME_COMPONENT(_moc_outfile_name ${outfile} NAME)
GET_FILENAME_COMPONENT(_moc_outfile_dir ${outfile} PATH)
IF(_moc_outfile_dir)
SET(_moc_working_dir WORKING_DIRECTORY ${_moc_outfile_dir})
ENDIF(_moc_outfile_dir)
SET (_moc_parameters_file ${outfile}_parameters)
SET (_moc_parameters ${moc_flags} ${moc_options} -o ${outfile}
${infile}) STRING (REPLACE ; \n _moc_parameters
${_moc_parameters}) FILE (WRITE ${_moc_parameters_file}
${_moc_parameters})
ADD_CUSTOM_COMMAND(OUTPUT ${outfile}
COMMAND ${QT_MOC_EXECUTABLE}
@${_moc_outfile_name}_parameters DEPENDS ${infile}
${_moc_working_dir}
VERBATIM)
ELSE (WIN32)
ADD_CUSTOM_COMMAND(OUTPUT ${outfile}
COMMAND ${QT_MOC_EXECUTABLE}
ARGS ${moc_flags} ${moc_options} -o ${outfile}
${infile} DEPENDS ${infile})
ENDIF (WIN32)
ENDMACRO (QT4_CREATE_MOC_COMMAND)
Is this on purpose? Adding VERBATIM to the ADD_CUSTOM_COMMAND calls in
that file solved the quoting issue and allowed me to build without any
problems. Is that project just misusing cmake, or is it really a
problem with Qt4Macros.cmake?
Regards,
Pierre-Francois
--
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
--
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
Re: [CMake] SCC bindings missing AUXPATH support?
I have added source code support for this myself. I updated the following files: cmLocalVisualStudio7Generator.cxx cmLocalVisualStudio10TargetGenerator.cxx The existing SCC support code was already in these files, I just added the SccAuxPath support to it. I'm not an expert at creating patch files outside of TortoiseSVN on Windows, so could someone explain how to create a patch file for these on Windows 7? Also how would you like me to deliver the code? I hope to see it introduced in version 2.8.7 Thanks. - Robert Dailey On Mon, Oct 31, 2011 at 4:10 PM, Robert Dailey rcdai...@gmail.com wrote: There are actually 4 SCC related key/value pairs used in VS2003 VCPROJ files: SccProjectName=SAK SccAuxPath=SAK SccLocalPath=SAK SccProvider=SAK CMake supports these 3 via set_target_properties(): VS_SCC_LOCALPATH VS_SCC_PROJECTNAME VS_SCC_PROVIDER Apparently one more is needed to support SccAuxPath: VS_SCC_AUXPATH Can someone add support for this? Thanks. - 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
Re: [CMake] SCC bindings missing AUXPATH support?
I fiddled around with TortoiseGit and managed to create the patch. It is attached. Please integrate this into your repository so it is included in version 2.8.7 :) - Robert Dailey On Mon, Oct 31, 2011 at 5:41 PM, Robert Dailey rcdai...@gmail.com wrote: I have added source code support for this myself. I updated the following files: cmLocalVisualStudio7Generator.cxx cmLocalVisualStudio10TargetGenerator.cxx The existing SCC support code was already in these files, I just added the SccAuxPath support to it. I'm not an expert at creating patch files outside of TortoiseSVN on Windows, so could someone explain how to create a patch file for these on Windows 7? Also how would you like me to deliver the code? I hope to see it introduced in version 2.8.7 Thanks. - Robert Dailey On Mon, Oct 31, 2011 at 4:10 PM, Robert Dailey rcdai...@gmail.com wrote: There are actually 4 SCC related key/value pairs used in VS2003 VCPROJ files: SccProjectName=SAK SccAuxPath=SAK SccLocalPath=SAK SccProvider=SAK CMake supports these 3 via set_target_properties(): VS_SCC_LOCALPATH VS_SCC_PROJECTNAME VS_SCC_PROVIDER Apparently one more is needed to support SccAuxPath: VS_SCC_AUXPATH Can someone add support for this? Thanks. - Robert Dailey 0001-Add-support-for-SccAuxPath-tag-in-VCPROJ-files.-Set-.patch Description: Binary data -- 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] SCC bindings missing AUXPATH support?
I forgot to explain why I made the change to begin with. Basically this all
comes down to Perforce binding support. SccAuxPath is used to specify the
Perforce connection string. Without this, each project opened will prompt
the user for the information via modal dialog. This gets very annoying...
Here is an example of how I have setup each of my projects:
set_target_properties(
${project_name} PROPERTIES
VS_SCC_AUXPATH
P4SCC#${PERFORCE_SERVER}##${PERFORCE_USER}##${PERFORCE_WORKSPACE}
VS_SCC_LOCALPATH ${CMAKE_SOURCE_DIR}
VS_SCC_PROJECTNAME Perforce Project
VS_SCC_PROVIDER MSSCCI:Perforce SCM
)
All of the PERFORCE_ variables are cache variables, so that the user can
specify their credentials, server, and workspace. These are all formatted
into the connection string perforce expects.
The resulting XML in the VCPROJ looks like so:
SccProjectName=Perforce Project
SccLocalPath=C:/Code/work/sandbox
SccAuxPath=P4SCC#perforce.mycompany.com:3666##rdailey##rdailey-t510-sandbox
SccProvider=MSSCCI:Perforce SCM
When I open the generated solution, all projects load perfectly with no
prompts and everything is binded to source control :)
-
Robert Dailey
On Mon, Oct 31, 2011 at 7:06 PM, Robert Dailey rcdai...@gmail.com wrote:
I fiddled around with TortoiseGit and managed to create the patch. It is
attached.
Please integrate this into your repository so it is included in version
2.8.7 :)
-
Robert Dailey
On Mon, Oct 31, 2011 at 5:41 PM, Robert Dailey rcdai...@gmail.com wrote:
I have added source code support for this myself. I updated the following
files:
cmLocalVisualStudio7Generator.cxx
cmLocalVisualStudio10TargetGenerator.cxx
The existing SCC support code was already in these files, I just added
the SccAuxPath support to it.
I'm not an expert at creating patch files outside of TortoiseSVN on
Windows, so could someone explain how to create a patch file for these on
Windows 7? Also how would you like me to deliver the code? I hope to see it
introduced in version 2.8.7
Thanks.
-
Robert Dailey
On Mon, Oct 31, 2011 at 4:10 PM, Robert Dailey rcdai...@gmail.comwrote:
There are actually 4 SCC related key/value pairs used in VS2003 VCPROJ
files:
SccProjectName=SAK
SccAuxPath=SAK
SccLocalPath=SAK
SccProvider=SAK
CMake supports these 3 via set_target_properties():
VS_SCC_LOCALPATH
VS_SCC_PROJECTNAME
VS_SCC_PROVIDER
Apparently one more is needed to support SccAuxPath:
VS_SCC_AUXPATH
Can someone add support for this? Thanks.
-
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
[CMake] Symlinks not created on OS X
The OS X .dmg installer, cmake-2.8.6-Darwin64-universal.dmg, at http://www.cmake.org/cmake/resources/software.html, failed to install symlinks in /usr/bin as promised. I received six messages, I think from the Cmake app, of this nature: Failed create symlink installation may be incomplete: x where x was ccmake, cmake, cmake-gui, cmakexbuild, cpack, and ctest. I made the symlinks manually and things seem to work OK. OS X 10.6.8. Thanks, Jerry P.S. It might be a good idea to improve the English consruction of these messages. -- 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://ads.itgfiles.com/plugins/maintenanceStatisticsTask/oxMarketMaintenance/scripts/woflisv.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] Source control bindings feature in CMake needs better documentation
Hi Robert,
I don't pretend to know everything there is to know about Visual
Studio SCC integration, but I have gotten this to work before with a
bit of trial and error, and reverse-engineering the entries visual
studio creates for these properties.
To answer your most recent question, there is no way to specify
perforce connection/user/workspace information in the cmake file as
these properties are just forwarded to the generated .vcproj files,
and there is no way to set the parameters you are looking for there.
In your examples, [I have found that] the values you have for project
name and provider are correct when hooking up to perforce. However, I
think you are a bit off the mark on the first parameter to
set_target_properties. This is supposed to be the name of the
_target_ you are binding to scc (the result of a add_executable,
add_library command etc.) not the project name. In the cmake-VS
mapping, a cmake target is a VS project, and a cmake project is a VS
solution (so if you have a project command for every target, you can
most likely start simplifying things there). I mention this because it
may have something to do with the excessive prompting you are
getting... though reviewing my team's integration shows that we are
doing this same thing. Another thing you might want to adjust is the
local path I have had the most success with passing a path
relative to the target's binary directory using the target path format
(in this case, always windows... i.e. use back slashes. To compute
this dynamically, you may have success using file(RELATIVE_PATH) with
CMAKE_CURRENT_BINARY_DIR, and CMAKE_SOURCE_DIR. In VS2010, at least,
we have found that in order to avoid being prompted to save on exit,
we must strip trailing slashes from the path we build in this way.
Following this pattern, we have gotten to the point where we are
prompted once for port and workspace/clientspec on each invocation of
visual studio, but it is only once and not once per project in the
solution.
Steven
On Mon, Oct 31, 2011 at 2:36 PM, Robert Dailey rcdai...@gmail.com wrote:
While waiting on a response I did some experimentation:
set_target_properties(
${project_name} PROPERTIES
VS_SCC_LOCALPATH ${CMAKE_SOURCE_DIR}
VS_SCC_PROJECTNAME Perforce Project
VS_SCC_PROVIDER MSSCCI:Perforce SCM
)
This seems to work in VS 2003 but the annoying thing is that when I open the
solution, every single project (about 120 of them) each prompt me for my
username, workspace, and server URL to perforce server.
Is there no way to specify this connection/user/workspace information in
CMake so that when I open the solution it already knows this stuff?
-
Robert Dailey
On Mon, Oct 31, 2011 at 12:24 PM, Robert Dailey rcdai...@gmail.com wrote:
Hey guys,
Our team is running Perforce here at work and I want to setup any Visual
Studio projects generated to use source control bindings for Perforce.
The documentation for VS_SCC_PROJECTNAME, VS_SCC_LOCALPATH,
VS_SCC_PROVIDER is pretty bad and I really have no clue on how to use these.
Could someone explain what each is and possibly provide some examples on how
they are used for Perforce?
Thanks!!
-
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] Enhancing the Visual Studio Generators' Source Control integration
Hi All, We have noticed, that using the VS_SCC_* target properties, we can bind to a perforce SCM server. However, the way that SCC works the perforce plugin has to prompt the user for connection information. When we were doing this with hand-made visual studio solutions, we would only be prompted once when the workspace was fresh and clean, and the information would be retained thereafter. With our CMake-generated solutions, we are prompted on every invocation of visual studio. We'd like to get back to the fewer prompts workflow. After much research and trial and error, we have discovered that this seems to be because the bindings created by cmake are stored in the visual studio project files...and only there. It seems that a more complete binding also records some SCC-related properties in the solution file... Therefore, I started hacking on the visual studio generator to try and decipher how this functionality would be added to cmake, and made good progress. However, there are some solution file properties related to SCC that must be recorded for the solution itself. For most entries, I can just query the targets' VS_SCC_ properties, but there are no such properties for the solution/project. What's more, is there is no existing precedent, that I can find, for user-specified project properties. So I am not sure how I would be able to give the user control over what these properties may be. In my scenario, with the perforce SCC plugin, I _could_ get the necessary properties form the first target, but I doubt this is the general solution otherwise there is simply too much redundancy in the protocol/format. Long question short... is there an existing, reliable way for the user to provide per-project properties that the generator can get at? Thanks, Steven -- 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] SCC bindings missing AUXPATH support?
Hi Robert,
I reviewed the patch, and I am not sure vsAuxPath should be a
requirement. As I stated earlier, we've gotten the binding to work
acceptably without it and I assume others have as well. Further, some
users may prefer to enter their connection information in to the
perforce dialog on first invocation instead of having to configure the
cmake cache to setup their bindings.
To be clear, I have no objections to adding AuxPath support (not that
my objections count for anything around here). Its that just as it
stands now, if you don't supply it, you won't get any bindings.
Also, you may have better results getting your patch integrated by
opening a defect in cmake's bug tracker and attaching the patch to
that. The preferred patch generation method is also described here:
http://www.mail-archive.com/cmake@cmake.org/msg36619.html
By the way, as I stated in an earlier mail, if you wish to pursue this
further, if you change C:/Code/work/sandbox to ..\..\.. where that
path points to C:\Code\work\sandbox relative to the target being
bound, you should have better results.
Thanks,
Steven
On Mon, Oct 31, 2011 at 8:20 PM, Robert Dailey rcdai...@gmail.com wrote:
I forgot to explain why I made the change to begin with. Basically this all
comes down to Perforce binding support. SccAuxPath is used to specify the
Perforce connection string. Without this, each project opened will prompt
the user for the information via modal dialog. This gets very annoying...
Here is an example of how I have setup each of my projects:
set_target_properties(
${project_name} PROPERTIES
VS_SCC_AUXPATH
P4SCC#${PERFORCE_SERVER}##${PERFORCE_USER}##${PERFORCE_WORKSPACE}
VS_SCC_LOCALPATH ${CMAKE_SOURCE_DIR}
VS_SCC_PROJECTNAME Perforce Project
VS_SCC_PROVIDER MSSCCI:Perforce SCM
)
All of the PERFORCE_ variables are cache variables, so that the user can
specify their credentials, server, and workspace. These are all formatted
into the connection string perforce expects.
The resulting XML in the VCPROJ looks like so:
SccProjectName=Perforce Project
SccLocalPath=C:/Code/work/sandbox
SccAuxPath=P4SCC#perforce.mycompany.com:3666##rdailey##rdailey-t510-sandbox
SccProvider=MSSCCI:Perforce SCM
When I open the generated solution, all projects load perfectly with no
prompts and everything is binded to source control :)
-
Robert Dailey
On Mon, Oct 31, 2011 at 7:06 PM, Robert Dailey rcdai...@gmail.com wrote:
I fiddled around with TortoiseGit and managed to create the patch. It is
attached.
Please integrate this into your repository so it is included in version
2.8.7 :)
-
Robert Dailey
On Mon, Oct 31, 2011 at 5:41 PM, Robert Dailey rcdai...@gmail.com wrote:
I have added source code support for this myself. I updated the following
files:
cmLocalVisualStudio7Generator.cxx
cmLocalVisualStudio10TargetGenerator.cxx
The existing SCC support code was already in these files, I just added
the SccAuxPath support to it.
I'm not an expert at creating patch files outside of TortoiseSVN on
Windows, so could someone explain how to create a patch file for these on
Windows 7? Also how would you like me to deliver the code? I hope to see it
introduced in version 2.8.7
Thanks.
-
Robert Dailey
On Mon, Oct 31, 2011 at 4:10 PM, Robert Dailey rcdai...@gmail.com
wrote:
There are actually 4 SCC related key/value pairs used in VS2003 VCPROJ
files:
SccProjectName=SAK
SccAuxPath=SAK
SccLocalPath=SAK
SccProvider=SAK
CMake supports these 3 via set_target_properties():
VS_SCC_LOCALPATH
VS_SCC_PROJECTNAME
VS_SCC_PROVIDER
Apparently one more is needed to support SccAuxPath:
VS_SCC_AUXPATH
Can someone add support for this? Thanks.
-
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-commits] CMake branch, next, updated. v2.8.6-1726-g76d76f4
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 76d76f425f82daeb7450237ee2c47d4141e519d9 (commit)
via 3ebf9ed39bac5736b53bd455e2f5cdca381acaf9 (commit)
via e90849aed23c3673c3dc44b1573e2ee84ff02eda (commit)
via d481477962c6fd481bbcd4044011d7147c2f2837 (commit)
via becc5eeda23dd809134af5fe876be05400e9fa33 (commit)
via 07e88ae4499b63367eb5b4308cac2a89718f (commit)
via 3313cdeb3321d385b6d84bd5b0784337243316a1 (commit)
from 4f2b45203247a27c91f5d16f591cc4491a6ad0d4 (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=76d76f425f82daeb7450237ee2c47d4141e519d9
commit 76d76f425f82daeb7450237ee2c47d4141e519d9
Merge: 4f2b452 3ebf9ed
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Mon Oct 31 10:05:37 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Oct 31 10:05:37 2011 -0400
Merge topic 'qt4-deploy-module' into next
3ebf9ed Check plugin variables are defined before warning.
e90849a Don't resolve directories; are never relative.
d481477 Match fixup_qt4_executable with documentation.
becc5ee Merge branch 'master' of CMakeGit:cmake
07e88ae KWSys Nightly Date Stamp
3313cde Merge branch 'CodeBlocks-quoting'
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3ebf9ed39bac5736b53bd455e2f5cdca381acaf9
commit 3ebf9ed39bac5736b53bd455e2f5cdca381acaf9
Author: Mike McQuaid m...@mikemcquaid.com
AuthorDate: Fri Oct 28 17:33:21 2011 +0100
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Mon Oct 31 08:04:11 2011 -0600
Check plugin variables are defined before warning.
diff --git a/Modules/DeployQt4.cmake b/Modules/DeployQt4.cmake
index ef8dd1f..4bf1b6c 100644
--- a/Modules/DeployQt4.cmake
+++ b/Modules/DeployQt4.cmake
@@ -225,9 +225,11 @@ function(install_qt4_plugin plugin executable copy
installed_plugin_path_var)
else()
string(TOUPPER QT_${plugin}_PLUGIN plugin_var)
endif()
-set(plugin_release ${${plugin_var}_RELEASE})
-set(plugin_debug ${${plugin_var}_DEBUG})
-if(NOT EXISTS ${plugin_release} AND NOT EXISTS
${plugin_debug})
+set(plugin_release_var ${plugin_var}_RELEASE)
+set(plugin_debug_var ${plugin_var}_DEBUG)
+set(plugin_release ${${plugin_release_var}})
+set(plugin_debug ${${plugin_debug_var}})
+if(DEFINED ${plugin_release_var} AND DEFINED
${plugin_debug_var} AND NOT EXISTS ${plugin_release} AND NOT EXISTS
${plugin_debug})
message(WARNING Qt plugin \${plugin}\ not
recognized or found.)
endif()
install_qt4_plugin_path(${plugin_release} ${executable}
${copy} ${installed_plugin_path_var} ${plugins_dir} ${component}
Release|RelWithDebInfo|MinSizeRel)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e90849aed23c3673c3dc44b1573e2ee84ff02eda
commit e90849aed23c3673c3dc44b1573e2ee84ff02eda
Author: Mike McQuaid m...@mikemcquaid.com
AuthorDate: Fri Oct 28 17:32:28 2011 +0100
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Mon Oct 31 08:04:11 2011 -0600
Don't resolve directories; are never relative.
diff --git a/Modules/DeployQt4.cmake b/Modules/DeployQt4.cmake
index 3e20d34..ef8dd1f 100644
--- a/Modules/DeployQt4.cmake
+++ b/Modules/DeployQt4.cmake
@@ -151,7 +151,6 @@ function(fixup_qt4_executable executable)
endforeach()
resolve_qt4_paths(libs ${executable_path})
-resolve_qt4_paths(dirs ${executable_path})
if(write_qt_conf)
set(qt_conf_contents [Paths]\nPlugins = ${plugins_dir})
@@ -265,7 +264,6 @@ function(install_qt4_executable executable)
endforeach()
resolve_qt4_paths(libs)
-resolve_qt4_paths(dirs)
install(CODE
INCLUDE( \${DeployQt4_cmake_dir}/DeployQt4.cmake\ )
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d481477962c6fd481bbcd4044011d7147c2f2837
commit d481477962c6fd481bbcd4044011d7147c2f2837
Author: Mike McQuaid m...@mikemcquaid.com
AuthorDate: Fri Oct 28 17:31:30 2011 +0100
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Mon Oct 31 08:04:11 2011 -0600
Match fixup_qt4_executable with documentation.
diff --git a/Modules/DeployQt4.cmake b/Modules/DeployQt4.cmake
index bdf8360..3e20d34 100644
--- a/Modules/DeployQt4.cmake
+++ b/Modules/DeployQt4.cmake
@@ -56,7 +56,7 @@
# (or plugins_dir) relative to executable and store the result in
# installed_plugin_path_var. See
[Cmake-commits] CMake branch, next, updated. v2.8.6-1728-g855155a
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 855155aa120ac3aeddcadc73ebf45bc2fb376efe (commit) via 8c8305f286dab4e374bb8142ee991e00c57e418b (commit) from 76d76f425f82daeb7450237ee2c47d4141e519d9 (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=855155aa120ac3aeddcadc73ebf45bc2fb376efe commit 855155aa120ac3aeddcadc73ebf45bc2fb376efe Merge: 76d76f4 8c8305f Author: Alexander Neundorf neund...@kde.org AuthorDate: Mon Oct 31 17:12:03 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Oct 31 17:12:03 2011 -0400 Merge topic 'DontCrashAutomocWithEmptyCompileDefs' into next 8c8305f don't crash in automoc with empty COMPILE_DEFINITIONS property http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c8305f286dab4e374bb8142ee991e00c57e418b commit 8c8305f286dab4e374bb8142ee991e00c57e418b Author: Alex Neundorf neund...@kde.org AuthorDate: Mon Oct 31 22:07:12 2011 +0100 Commit: Alex Neundorf neund...@kde.org CommitDate: Mon Oct 31 22:07:12 2011 +0100 don't crash in automoc with empty COMPILE_DEFINITIONS property Reported by Laszlo Papp: http://www.cmake.org/pipermail/cmake/2011-October/047089.html Alex diff --git a/Source/cmQtAutomoc.cxx b/Source/cmQtAutomoc.cxx index a839489..fdc19e4 100644 --- a/Source/cmQtAutomoc.cxx +++ b/Source/cmQtAutomoc.cxx @@ -124,21 +124,22 @@ void cmQtAutomoc::SetupAutomocTarget(cmTarget* target) } } - std::string _moc_incs = makefile-GetProperty(INCLUDE_DIRECTORIES); - std::string _moc_defs = makefile-GetProperty(DEFINITIONS); - std::string _moc_compile_defs = makefile-GetProperty(COMPILE_DEFINITIONS); + const char* _moc_incs = makefile-GetProperty(INCLUDE_DIRECTORIES); + const char* _moc_defs = makefile-GetProperty(DEFINITIONS); + const char* _moc_compile_defs = makefile-GetProperty(COMPILE_DEFINITIONS); // forget the variables added here afterwards again: cmMakefile::ScopePushPop varScope(makefile); static_castvoid(varScope); makefile-AddDefinition(_moc_target_name, automocTargetName.c_str()); - makefile-AddDefinition(_moc_incs, _moc_incs.c_str()); - makefile-AddDefinition(_moc_defs, _moc_defs.c_str()); - makefile-AddDefinition(_moc_compile_defs, _moc_compile_defs.c_str()); + makefile-AddDefinition(_moc_incs, _moc_incs!=0 ? _moc_incs : ); + makefile-AddDefinition(_moc_defs, _moc_defs!=0 ? _moc_defs : ); + makefile-AddDefinition(_moc_compile_defs, + _moc_compile_defs!=0 ? _moc_compile_defs : ); makefile-AddDefinition(_moc_files, _moc_files.c_str()); makefile-AddDefinition(_moc_headers, _moc_headers.c_str()); - const char* cmakeRoot = makefile-GetDefinition(CMAKE_ROOT); + const char* cmakeRoot = makefile-GetSafeDefinition(CMAKE_ROOT); std::string inputFile = cmakeRoot; inputFile += /Modules/AutomocInfo.cmake.in; std::string outputFile = targetDir; --- Summary of changes: Source/cmQtAutomoc.cxx | 15 --- 1 files changed, 8 insertions(+), 7 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-1730-g768b869
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 768b869bc84effce48a4cd7ac7a4ae858f869813 (commit) via 057633151a527fc614b56f4ca3fd73f63928ebff (commit) from 855155aa120ac3aeddcadc73ebf45bc2fb376efe (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=768b869bc84effce48a4cd7ac7a4ae858f869813 commit 768b869bc84effce48a4cd7ac7a4ae858f869813 Merge: 855155a 0576331 Author: Alexander Neundorf neund...@kde.org AuthorDate: Mon Oct 31 18:41:22 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Oct 31 18:41:22 2011 -0400 Merge topic 'FixTargetsInVirtualFoldersForEclipseIndigo' into next 0576331 Eclipse: make targets work from any directory http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=057633151a527fc614b56f4ca3fd73f63928ebff commit 057633151a527fc614b56f4ca3fd73f63928ebff Author: Alex Neundorf neund...@kde.org AuthorDate: Mon Oct 31 23:37:01 2011 +0100 Commit: Alex Neundorf neund...@kde.org CommitDate: Mon Oct 31 23:37:01 2011 +0100 Eclipse: make targets work from any directory Set the working directory for make targets which are associated to virtual folders, otherwise Eclipse simply runs make from the current working directory (where Eclipse has been started), and where probably not the correct makefile is located. Alex diff --git a/Source/cmExtraEclipseCDT4Generator.cxx b/Source/cmExtraEclipseCDT4Generator.cxx index 785e85a..eab149e 100644 --- a/Source/cmExtraEclipseCDT4Generator.cxx +++ b/Source/cmExtraEclipseCDT4Generator.cxx @@ -998,7 +998,11 @@ void cmExtraEclipseCDT4Generator::CreateCProjectFile() const std::string virtDir = [Targets]/; virtDir += prefix; virtDir += ti-first; - this-AppendTarget(fout, Build, make, makeArgs, virtDir, , + std::string buildArgs = -C ; + buildArgs += makefile-GetHomeOutputDirectory(); + buildArgs += ; + buildArgs += makeArgs; + this-AppendTarget(fout, Build, make, buildArgs, virtDir, , ti-first.c_str()); std::string cleanArgs = -E chdir \; --- Summary of changes: Source/cmExtraEclipseCDT4Generator.cxx |6 +- 1 files changed, 5 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
