Re: Qt static libraries - pkgconfig again
Von: Thiago Macieira <[EMAIL PROTECTED]> > [EMAIL PROTECTED] wrote: > >> kdelibs does not build because QtUiTools is missing a dependency when > >> linking kjsembed. > > > >Can't we get around this problem by convincing the trolls to not make it > > a static lib? > > I doubt that. QtUiTools is a very small library whose purpose is to load > designer-generated .ui files. > > > Or by parsing the .prl-files. > > That would not be recommended. Those files are not documented anywhere and > could change format any time. > > > Can't qmake tell us what deps we need? > > I guess it could. But there doesn't seem to be an easy way of doing that. > maybe we should ask the trolls here - it looks quite easy to make qmake parse the .prl-files and print out QMAKE_PRL_LIBS. > > What depenency is missing? > > QtScript. > My fault - it's to early in the morning ;) > > I need to compile qt4.3 on win32 to see if we really need to add this > > dependency - can you tell me more what's missing? > > > >The directory layout on win32 does not allow a pkg-config tool as every > > program has it's own subdirectory without a common place for > > .pkg-config - files. We've enough problems with other external > > libs/tools on win32 - adding another one would just rise the level for > > new devs once more :( > > We can use pkg-config for Qt only, at least. Fortunately, none of the Qt > library .pc files has external dependencies, so they will parse easily by > pkg-config with just one dir in $PKG_CONFIG_PATH. > > In any case, shouldn't Windows start having a common pkgconfig path then? > A common path is hard to introduce - every user has to have access right to the common directory. Then it's maybe better to extend to PKG_CONFIG_PATH variable. But I doubt Qt 4.3 is doing that... If not, maybe cmake has to extend the pkg-config path (or parse the .pc - file directly). I have to take a look on this on weekend. Christian -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
[EMAIL PROTECTED] wrote: >> kdelibs does not build because QtUiTools is missing a dependency when >> linking kjsembed. > >Can't we get around this problem by convincing the trolls to not make it > a static lib? I doubt that. QtUiTools is a very small library whose purpose is to load designer-generated .ui files. > Or by parsing the .prl-files. That would not be recommended. Those files are not documented anywhere and could change format any time. > Can't qmake tell us what deps we need? I guess it could. But there doesn't seem to be an easy way of doing that. > What depenency is missing? QtScript. > I need to compile qt4.3 on win32 to see if we really need to add this > dependency - can you tell me more what's missing? > >The directory layout on win32 does not allow a pkg-config tool as every > program has it's own subdirectory without a common place for > .pkg-config - files. We've enough problems with other external > libs/tools on win32 - adding another one would just rise the level for > new devs once more :( We can use pkg-config for Qt only, at least. Fortunately, none of the Qt library .pc files has external dependencies, so they will parse easily by pkg-config with just one dir in $PKG_CONFIG_PATH. In any case, shouldn't Windows start having a common pkgconfig path then? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpyxna3dPC4o.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Von: Thiago Macieira <[EMAIL PROTECTED]> > Christian Ehrlicher wrote: > >pkg-config on win32 is a bad idea... :( > > If you want to compile KDE with Qt 4.3, you'll need it. > > kdelibs does not build because QtUiTools is missing a dependency when > linking kjsembed. > Can't we get around this problem by convincing the trolls to not make it a static lib? Or by parsing the .prl-files. Can't qmake tell us what deps we need? What depenency is missing? I need to compile qt4.3 on win32 to see if we really need to add this dependency - can you tell me more what's missing? The directory layout on win32 does not allow a pkg-config tool as every program has it's own subdirectory without a common place for .pkg-config - files. We've enough problems with other external libs/tools on win32 - adding another one would just rise the level for new devs once more :( Christian -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Christian Ehrlicher wrote: >pkg-config on win32 is a bad idea... :( If you want to compile KDE with Qt 4.3, you'll need it. kdelibs does not build because QtUiTools is missing a dependency when linking kjsembed. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgp946FKZMSlm.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Qt static libraries - pkgconfig again
Thiago Macieira schrieb: Qt has one static library that we use in KDE code: QtUiTools. Whichever reason the Trolls had to make it static is besides the point: it is static. That means we must fetch its dependency info from the Qt installation into CMake. And Qt provides only one official way of doing that: via pkg-config. So, I ask again: can we start supporting discovery of Qt via pkg-config by default on all systems? If that doesn't work, we'd have a fallback to the current discovery via qmake. pkg-config on win32 is a bad idea... :( Christian signature.asc Description: OpenPGP digital signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Qt static libraries - pkgconfig again
Qt has one static library that we use in KDE code: QtUiTools. Whichever reason the Trolls had to make it static is besides the point: it is static. That means we must fetch its dependency info from the Qt installation into CMake. And Qt provides only one official way of doing that: via pkg-config. So, I ask again: can we start supporting discovery of Qt via pkg-config by default on all systems? If that doesn't work, we'd have a fallback to the current discovery via qmake. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpU2YhVx5pzS.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: disable progressinfo?
On Thursday 22 February 2007 11:28, Dirk Mueller wrote: > On Thursday, 22. February 2007 11:17, Dirk Mueller wrote: > > Is there some (undocumented) way of getting rid of all this fancy stuff > > that nobody needs? > > To be more precise: > > I don't want it to output progress information when it might not have done > anything "heavy". for example the "Built target" output: most of the time > there is just nothing done, so you're causing make to fork() and exec > cmake, while it could have just skipped evaluation of the target rules > (which would probably be faster, and not cause konsole to scroll > unnecessarily). So it's not about the progress percentage, is it ? Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org- http://www.kde.org alex AT neundorf.net - http://www.neundorf.net ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: disable progressinfo?
On Thursday, 22. February 2007 11:17, Dirk Mueller wrote: > Is there some (undocumented) way of getting rid of all this fancy stuff > that nobody needs? To be more precise: I don't want it to output progress information when it might not have done anything "heavy". for example the "Built target" output: most of the time there is just nothing done, so you're causing make to fork() and exec cmake, while it could have just skipped evaluation of the target rules (which would probably be faster, and not cause konsole to scroll unnecessarily). Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
disable progressinfo?
Hi, the progress information is getting on my nerves: [ 56%] Built target kprotocolinfotest [ 56%] Built target kruntest [ 56%] [ 56%] Built target kscantest first of all there seem to be sometimes duplicate percentages in one line. Also, I don't like that every "make" in kdelibs prints > 200 lines without actually doing anything. It just feels slow, and makes me use konsole history scrollback much more often than actually necessary. Is there some (undocumented) way of getting rid of all this fancy stuff that nobody needs? Thanks, Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: how to build generated sources in parallel with out linking them together?
On Thursday, 22. February 2007 10:51, Thiago Macieira wrote: > What were those linking errors? Were they justified? In some cases, they are, like for example virtual inline functions. In some other cases, they were not (missing #include caused gcc to interpret type attributes as instantiation names). Overall the idea of building them in-place has to be scratched, #include ".." vs <> doesn't have the right meaning. I've written a 6 line gnu makefile that does the same thing and added it to the dashboard. (its not yet causing an error though because I first want to make sure that kdelibs passes before enabling it). Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: how to build generated sources in parallel with out linking them together?
Am Donnerstag, 22. Februar 2007 10:51 schrieb Thiago Macieira: > Stephan Kulow wrote: > >It's even worse. Linking will break in some cases > > Oh? I would think they should all compile and link. > > What were those linking errors? Were they justified? I'm not expert enough to tell you if they are justified, but KHttpCookieList (which is defined in an internal header I excluded later from checking) complained that it's missing Q3Glist definition Greetings, Stephan ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: how to build generated sources in parallel with out linking them together?
Stephan Kulow wrote: >It's even worse. Linking will break in some cases Oh? I would think they should all compile and link. What were those linking errors? Were they justified? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpy3O5TXJ27r.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: how to build generated sources in parallel with out linking them together?
Am Donnerstag, 22. Februar 2007 00:21 schrieb Brad King: > For the VS IDE generators there does not seem to be a way to compile > sources without archiving them, but since the objects contain only a few > symbols they should not be too big. It's not necessary to do this for any but one platform, so this is ok. Greetings, Stephan ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: how to build generated sources in parallel with out linking them together?
Am Mittwoch, 21. Februar 2007 23:31 schrieb Thiago Macieira:
> Alexander Neundorf wrote:
> >If I link some compiled headers without -no-undefined, it seems to work.
> >Am I missing something ?
>
> Basically we want to:
>
> ==
> #define QT_NO_CAST_FROM_ASCII
> #define QT_NO_CAST_TO_ASCII
> #define QT_NO_KEYWORDS
>
> #define signals choke
> #define slots choke
> #define foreach choke
> #define forever choke
>
> #include
> static void dummy() { }
> =
>
> and make sure that that compiles with Dirk's usual very strict compiler
> switches (-pedantic -ansi -Wall -W -Werror, etc.)
>
> Since that's just an empty file and will produce hardly any symbols,
> there's no need to link.
It's even worse. Linking will break in some cases
Greetings, Stephan
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
