On Monday 20 March 2006 22:32, Alexander Dymo wrote:
Hi!
Is there anybody working on getting doxygen docs generated with cmake.
What's the plan of doing that? I like the good old way of
setting project name and listing references in Makefile.am
and I'd like to reproduce this with cmake. If
Bill Hoffman wrote:
In the FindQ4.cmake in CMake, I look for qmake like this:
1. CMAKE_PROGRAM_PATH - environment variable
2. CMAKE_PROGRAM_PATH - cmake variable (specified with a -D on the
command line) 3. PATH - environment variable
4. CMAKE_SYSTEM_PROGRAM_PATH - this is a per platform set
In the FindQ4.cmake in CMake, I look for qmake like this:
1. CMAKE_PROGRAM_PATH - environment variable
2. CMAKE_PROGRAM_PATH - cmake variable (specified with a -D on the command line)
3. PATH - environment variable
4. CMAKE_SYSTEM_PROGRAM_PATH - this is a per platform set of directories
On Tuesday 21 March 2006 14:36, Thiago Macieira wrote:
The very first one should be the pkg-config check, on Unix platforms.
I disagree. Things specified on the command-line should always override
autodetection from the system.
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work
At 08:36 AM 3/21/2006, Thiago Macieira wrote:
The very first one should be the pkg-config check, on Unix platforms. I
also guess the very first one on Windows should be the registry check.
$ pkg-config --variable=prefix QtCore
/home/tjmaciei/troll/qt-4.1-build
If Qt is not found using
Hi,
I have this code:
set(COMBINEDHEADERSICAL
${CMAKE_SOURCE_DIR}/libkcal/libical/src/libical/icalversion.h
${CMAKE_SOURCE_DIR}/libkcal/libical/src/libical/icaltime.h
${CMAKE_SOURCE_DIR}/libkcal/libical/src/libical/icalduration.h
On Tuesday 21 March 2006 14:02, David Faure wrote:
I think the idea was to have independent shell scripts rather than
integrating doxygen docs into the building process. See the work by Adriaan
de Groot (and his last post on this list).
I see now. Ok, but what about portability of the script?
At 10:56 AM 3/21/2006, Allen Winter wrote:
In FindKDE4Internal.cmake I'd like to at least setup the framework for
supporting different C/C++ compilers, including icecream, icc, etc.
I assume we want to support the $CC and $CXX environment variables,
and also the CMAKE_C_COMPILER and
On Tuesday 21 March 2006 11:45, you wrote:
At 10:56 AM 3/21/2006, Allen Winter wrote:
In FindKDE4Internal.cmake I'd like to at least setup the framework for
supporting different C/C++ compilers, including icecream, icc, etc.
I assume we want to support the $CC and $CXX environment variables,
William A. Hoffman wrote:
That seems a bit harsh. For example, my build and install of qt-copy
would not work in that case. There are potential users that would not
have root access, and may want to install qt into a home directory. And
pkg-config would not know anything about those installs
At 12:01 PM 3/21/2006, Allen Winter wrote:
So in FindKDE4Internal.cmake we don't check against the $CC or the $CXX
environment variables.
All we need to do is look at ${CMAKE_C_COMPILER} and ${CMAKE_CXX_COMPILER} and
change the flags, optimization and debug level options depending on those
On Tuesday 21 March 2006 15:55, Laurent Montel wrote:
Hi,
I have this code:
set(COMBINEDHEADERSICAL
${CMAKE_SOURCE_DIR}/libkcal/libical/src/libical/icalversion.h
${CMAKE_SOURCE_DIR}/libkcal/libical/src/libical/icaltime.h
${CMAKE_SOURCE_DIR}/libkcal/libical/src/libical/icalduration.h
On Tuesday 21 March 2006 14:36, Thiago Macieira wrote:
Bill Hoffman wrote:
In the FindQ4.cmake in CMake, I look for qmake like this:
1. CMAKE_PROGRAM_PATH - environment variable
2. CMAKE_PROGRAM_PATH - cmake variable (specified with a -D on the
command line) 3. PATH - environment variable
On Tuesday 21 March 2006 20:08, Alexander Neundorf wrote:
The reason why I moved QTDIR to the first position is because it is
simple. On my system the Qt3 bin/ dir is in the PATH, while the Qt4
bin/ dir isn't. Is this broken ?
On SuSE they both point to the default Qt3 installation.
At 01:08 PM 3/21/2006, Alexander Neundorf wrote:
Ok, then I have two broken systems here, on both I compiled qt-copy and did
make install.
Having to mess around with setting up pkgconfig manually in order to be able
to compile KDE is no option IMO.
I'll add the pkgconfig results as the first
On Tuesday 21 March 2006 16:36, Andras Mantia wrote:
Hi,
Now that I find how to subscribe to the mailing list, I post my problem
here as well, maybe it's a better place than kde-core-devel. I'm trying
to build kdelibs trunk in a buildir!=srcdir setup.
Right now during make I get this
On Tuesday 21 March 2006 20:26, Andras Mantia wrote:
Another problem is that now it works inconsistently. If you pass the
-DQT_QMAKE_EXECUTABLE with the right path when running cmake it will
find it, but as soon as you run make, it will complain again.
I withdraw this. Now it seems to work
On Tuesday 21 March 2006 20:01, Alexander Neundorf wrote:
Is it possible that you have some leftovers of an in-source build or
an out-of-source build from 16th march to 19th march in your source
tree ? If there are some, they usually hurt.
Most probably this was the cause.
Simple solution:
On Tuesday 21 March 2006 19:27, Thiago Macieira wrote:
William A. Hoffman wrote:
I sort of like the idea of just putting qmake in your path.
Once you find the right qmake, you can use qmake to find all the
rest of qt. What is the official qt build time environment supposed
to be? I was
At 01:27 PM 3/21/2006, Thiago Macieira wrote:
time environment?
You need to find qmake only if you're using qmake to build your
application. If you are using qmake, you aren't using cmake.
So I don't see the point in finding it at all.
Because it is always part of qt, and we can use it to
On Thursday 23 February 2006 15:57, Brad King wrote:
David Faure wrote:
On Thursday 23 February 2006 15:30, Brad King wrote:
David Faure wrote:
Also, somehow something deletes many .o files during the build process so
I can't
see exactly why so many files have to be rebuilt, make -d
David Faure wrote:
On Thursday 23 February 2006 15:57, Brad King wrote:
With VERBOSE makefiles or by running make VERBOSE=1 CMake prints
information about what the dependency scanning is doing. The output
looks like
Dependee /some/header.h is newer than depender some/object.o
make
On Tuesday 21 March 2006 20:04, David Faure wrote:
On Tuesday 21 March 2006 19:55, David Faure wrote:
VERBOSE=1 make
Works much better. Thanks!
.. at least for .h changes triggering .o rebuilds.
It doesn't tell anything about libfoo.so has changed so I need to rebuild
libbar.so and
Alexander Neundorf schrieb:
SVN commit 521183 by neundorf:
-change FindLibXml2.cmake to the new enhanced cmake style by using
PATH_SUFFIXES
for linux/bsd/OS X developers this shouldn't change anything
...but for the windows developers it should !
So: for the stuff which comes from
Hello,
finally, I'm subscribed too! :)
First mail, first question: imagine I have a string made by a newline
character only, ie the line
message(STATUS myvar: \${myvar}\)
would output
-- Found ...
-- myvar:
-- Found ...
Doing a
STRING(REGEX REPLACE \\n?\\r? myvar ${myvar})
have the result to
On Tuesday 21 March 2006 19:00, Alexander Neundorf wrote:
This must be done differently.
The command is executed during the build, calling a macro gets executed
during cmake time, so you can't add a dependency to it.
Ok I understand.
Instead you probably need an additional custom command,
Pino Toscano wrote:
Hello,
finally, I'm subscribed too! :)
First mail, first question: imagine I have a string made by a newline
character only, ie the line
message(STATUS myvar: \${myvar}\)
would output
-- Found ...
-- myvar:
-- Found ...
Doing a
STRING(REGEX REPLACE \\n?\\r?
Hi,
after the discussions today on the KDE and the cmake mailing lists, it seems
that Qt4 obsoletes the use of QTDIR and instead requires that qmake is
available via PATH.
So I changed the detection of Qt4 accordingly in FindQt4.cmake.
This means:
to detect Qt4, use something like
export
Howdy,
In kdelibs/kio/kfile there is compile error in kfileiconview.moc
(removeToolTip was not declared in this scope).
So I cd into that subdir, and look for removeToolTip, which is found only in
kfileiconview.moc.
Hmm.. so I remove kfileiconview.moc and run 'make'.
Which re-runs the entire
29 matches
Mail list logo
