Re: playground/devtools/kdevelop4-extra-plugins/python/parser
Andreas Pakulat wrote: Add -fPIC, that seems to be the only option to use a static lib in a plugin on 64Bit platforms No, the correct solution is to not use a static lib at all. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On 05.07.07 21:09:23, Matt Rogers wrote: On Jul 5, 2007, at 6:01 PM, Andreas Pakulat wrote: SVN commit 684033 by apaku: Add -fPIC, that seems to be the only option to use a static lib in a plugin on 64Bit platforms CCing kde-buildsystem because I'm not sure this is the right thing to do. Making it a shared library is a problem because parts of the code is generated and the generator doesn't allow to add EXPORT macro's. The question is: Use -fPIC or build a shared lib that has visibility=default instead of hidden? CCMAIL:kde-buildsystem@kde.org Yes, this is wrong, IIRC. This needs to be a shared lib with its own export macro instead. Then somebody has to add an option to kdevelop-pg to tell it such a macro. Andreas -- Today is the tomorrow you worried about yesterday. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On Friday, 6. July 2007, Andreas Pakulat wrote: Add -fPIC, that seems to be the only option to use a static lib in a plugin on 64Bit platforms no, link the sources directly instead of adding a static library. Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On 06.07.07 11:26:57, Dirk Mueller wrote: On Friday, 6. July 2007, Andreas Pakulat wrote: Add -fPIC, that seems to be the only option to use a static lib in a plugin on 64Bit platforms no, link the sources directly instead of adding a static library. Thats not feasible, because some of the sources (though not all) may be generated (or may be not generated if the generator is missing) and thus I'd have to copy the generation code into each CMakeLists.txt that wants to use the sources. Andreas -- The whole world is a tuxedo and you are a pair of brown shoes. -- George Gobel ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
win32 build system issue
Hi,
I have installed kdelibs into d:\Programme\kdelibs and I'm going to
install kdebase into d:\Programme\kdebase. The separate dirs are used
for packaging.
At least on win32 i have a problems with the dbus interface directory
settings:
kdelibs installs dbus interface files into a directory named
DBUS_INTERFACES_DIR which is
CMAKE_INSTALL_PREFIX/share/dbus-1/interfaces (see FindKDE4Internals.cmake)
In kdebase/runtime/uiserver/CMakeLists.txt there is the
DBUS_INTERFACES_DIR variable used to find xml files installed by kdelibs.
When i configure kdebase to use the installed kdelibs in
d:\Programme\kdelibs, i added the PATH of kde4-config to the
applications search path and cmake does the rest.
Unfortunally then DBUS_INTERFACES_DIR is set to a directory based on the
kdebase install dir, which let cmake fails to find the interface files
for uiserver. See the related definition below.
qt4_add_dbus_interface(kuiserver_KDEINIT_SRCS
${DBUS_INTERFACES_DIR}/org.kde.UiServerCallbacks.xml callbacksiface )
qt4_add_dbus_adaptor(kuiserver_KDEINIT_SRCS
${DBUS_INTERFACES_DIR}/org.kde.UiServer.xml uiserver.h UIServer
uiserveradaptor )
Wen i set the DBUS_INTERFACE_DIR in kdebase CMakeCache.txt to the
location, where kdelibs has it's interfaces, the interfaces are found,
but now the installation of dbus interfaces located in kdebase goes into
the kdelibs install directory which is not expected.
-- Installing d:/Programme/kdebase/share/kde4/services/media.protocol
-- Installing
d:/Programme/kdelibs/share/dbus-1/interfaces/org.kde.MediaManager.xml
As far as I can see a solution may be to split the install dbus
interface dir from the referenced dbus interface directories. Any hints
how to solve this problem ?
Ralf
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
automoc v2
Hi,
attached you'll find the next generation of automoc
I replaced kde4automoc.cmake with a C++/QtCore based program that can run more
efficient.
Instead of creating a targetname.automoc file that is added to the target I
create a targetname_automoc.cpp file now that is compiled and linked into
the target. This file #includes all moc files that are not included by other
source files. This way the automoc can, at make-time, decide what mocs need
to be compiled explicitly and linked into the target.
E.g. the following is possible now:
foo.h:
class A : public QObject
{
Q_OBJECT
...
};
foo.cpp does not #include foo.moc
run make - everything compiles and links fine (without mentioning the header
in KDE4_MOC_HEADERS either since the new automoc looks at all corresponding
header files from the .cpp files by itself)
now change foo.cpp to #include foo.moc
running make now will just work, even with the /fast target.
Next change I did was to create a targetname_automoc.cpp.files file to pass
the moc includes and the source files that belong to the target to the
automoc. I could have kept it on the command line but I got a report that the
command line was already too long for Windows' cmd.exe.
Implementation details:
- The messages of the automoc are written using cmake -E cmake_echo_color, so
the automoc correctly colorizes its messages now.
- The moc QProcesses are started in parallel (up to 10).
Please test and let me know if you have any problems (you might have to remove
some explicit QT4_WRAP_CPP calls from CMakeLists.txt now). I'd like to commit
soon, as this is supposed to fix compilation on Windows again...
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: automoc/kde4automoc.cpp
===
--- automoc/kde4automoc.cpp (revision 0)
+++ automoc/kde4automoc.cpp (revision 0)
@@ -0,0 +1,270 @@
+/* This file is part of the KDE project
+Copyright (C) 2007 Matthias Kretz [EMAIL PROTECTED]
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License version 2
+as published by the Free Software Foundation.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301, USA.
+
+*/
+
+#include QtCore/QCoreApplication
+#include QtCore/QDateTime
+#include QtCore/QFile
+#include QtCore/QFileInfo
+#include QtCore/QHash
+#include QtCore/QProcess
+#include QtCore/QQueue
+#include QtCore/QRegExp
+#include QtCore/QStringList
+#include QtCore/QTextStream
+#include QtCore/QtDebug
+#include cstdlib
+
+class AutoMoc
+{
+public:
+AutoMoc();
+~AutoMoc();
+void run();
+
+private:
+void generateMoc(const QString sourceFile, const QString mocFileName);
+void usage(const QString );
+void echoColor(const QString msg)
+{
+QProcess cmakeEcho;
+cmakeEcho.setProcessChannelMode(QProcess::ForwardedChannels);
+QStringList args(cmakeEchoColorArgs);
+args msg;
+cmakeEcho.startDetached(cmake, args);
+}
+
+QString bindir;
+QString mocExe;
+QStringList mocIncludes;
+QStringList cmakeEchoColorArgs;
+const bool verbose;
+QTextStream cerr;
+QTextStream cout;
+QQueueQProcess * mocProcesses;
+};
+
+void AutoMoc::usage(const QString path)
+{
+cout usage: path outfile srcdir bindir moc executable endl;
+::exit(EXIT_FAILURE);
+}
+
+int main(int argc, char **argv)
+{
+QCoreApplication app(argc, argv);
+AutoMoc().run();
+return 0;
+}
+
+AutoMoc::AutoMoc()
+: verbose(!QByteArray(getenv(VERBOSE)).isEmpty()), cerr(stderr), cout(stdout)
+{
+const QByteArray colorEnv = getenv(COLOR);
+cmakeEchoColorArgs -E cmake_echo_color QString(--switch=) + colorEnv --blue
+ --bold;
+}
+
+void AutoMoc::run()
+{
+const QStringList args = QCoreApplication::arguments();
+Q_ASSERT(args.size() 0);
+if (args.size() 4) {
+usage(args[0]);
+}
+QFile outfile(args[1]);
+const QFileInfo outfileInfo(outfile);
+
+QString srcdir(args[2]);
+if (!srcdir.endsWith('/')) {
+srcdir += '/';
+}
+bindir = args[3];
+if (!bindir.endsWith('/')) {
+bindir += '/';
+}
+mocExe = args[4];
+
+QFile dotFiles(args[1] + .files);
+dotFiles.open(QIODevice::ReadOnly |
Re: automoc v2
On Saturday 07 July 2007, Matthias Kretz wrote: Instead of creating a targetname.automoc file that is added to the target I create a targetname_automoc.cpp file now that is compiled and linked into the target. This file #includes all moc files that are not included by other source files. This way the automoc can, at make-time, decide what mocs need to be compiled explicitly and linked into the target. Does this solve the following problem? I renamed a header file (say foo.h to bar.h), and with the current code (foo.automoc created), I got some dependency error on foo.automoc. Thanks for your excellent work on this topic. Next step, putting moc's own code into kde4automoc? :-PJust kidding. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
