2009/9/21 Stefan Majewsky <[email protected]>: > Another idea: We use the same CMakeLists, but in the parent directory of > KoProperty, we define some variable ${KOPROPERTY_TARGETNAME}, which is used > anywhere in the CMakeLists instead of the target name "koproperty". This > should make it easier to keep the CMakeLists in sync (e.g. if I want to add or > remove some files from the build) while avoiding conflicts. I would set the > variable to something like "kolfproperty" then, while you stay with > "koproperty".
OK, feel free to commit this change (assuming you also commit addition to koffice/kexi/CMakeLists.txt). >> Then I also propose to remove the install( FILES ***.h ... ) section. >> We'd avoid conflicts this way I guess. > > +1 I mean rather: comment out them. I also don't need to install them in case of kexi. >> I hope kdelibs wont become such a kitchen sink for everything we have.. >> It is already enough to use it on stripped down installations and on the >> mobile. > > If only kdelibs was as modular as Qt. > >> So yes, I wish we had the lib in kdesupport. > > Okay, noted inside my brain. I'll not insert any KDE dependencies. Actually we have them, but as said, can be moved to separate libraries providing factory(ies). So you can do the same if you need editors that are even dependent on Kolf. Also regarding being part of Qt - I don't think so, since the generic answer so far was "we have already propety editor provided by Designer". IIRC there was 1 additional project (or even 2) in Qt Solutions, looks like dropped already. -- regards / pozdrawiam, Jaroslaw Staniek Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org) KDE Libraries for MS Windows (http://windows.kde.org) http://www.linkedin.com/in/jstaniek _______________________________________________ Kexi mailing list [email protected] https://mail.kde.org/mailman/listinfo/kexi
