On Sunday 02 April 2006 19:48, you wrote: > On Sunday 02 April 2006 16:38, Allen Winter wrote: > > On Sunday 02 April 2006 14:21, David Faure wrote: > > > On Friday 31 March 2006 21:20, Allen Winter wrote: > > > > On Friday 31 March 2006 13:51, Alexander Neundorf wrote: > > > > > On Friday 31 March 2006 20:38, Allen Winter wrote: > > > > > > On Friday 31 March 2006 11:58, Alexander Neundorf wrote: > > > > > > > > > > ... > > > > > > > > > > > > Maybe we should create a file > > > > > > > "kdelibs/cmake/modules/KDE4Defaults.cmake" or something like > > > > > > > this, which contains all these settings > > > > > > Excellent idea ! > > > This way we can centralize > > > 1) the forbidding of srcdir==builddir > > > 2) the setting of CMAKE_INCLUDE_CURRENT_DIR to ON > > > 3) the enabling of colors > > > > 4) the enabling of verbosity > > etc > > > > > > > > > and e.g. also the FOO_INSTALL_DIR variables. > > > > > > Hmm, that's part of the kde4 paths, which apps -must- use when > > > installing. I thought the idea of separating those 'defaults' is that > > > they are actually optional; if a 3rd-party app developer already uses > > > cmake with his own settings, he should use FindKDE4Internal but he > > > doesn't have to load KDE4Defaults.cmake. Otherwise what's the point of > > > splitting it out? > > > > > > > > Yes, exactly. > > > > > It would go into kdelibs/cmake/modules/, and be installed to > > > > > share/apps/cmake/modules/ > > > > > > Yep. > > > > > > > Another alternative: put KDE4Defaults.cmake into the admin directory. > > > > And since the admin directory is imported into each modules repository > > > > we get the duplication for free. > > > > > > No, no - forget about admin. It will go away. We won't need it anymore. > > > Duplication sucks, even when automated - so why have duplication when we > > > can just do "make install" in kdelibs and get the file for all other > > > modules to use? > > > > > > [ok we'll see what happens once we have to deal with kde-4.0-final's > > > installed cmake files being used by every 3rd party apps and then we > > > can't change anything in an incompatible way in those files... I just > > > hope we'll have *really* stabilized everything by then.] > > > > Worst case is that we have some stuff that will need to be hand-duplicated > > across all the CMakeList.txt files.. I think. Even though it is a pain to > > do that. > > > > I sorta liked having a karma-protected admin dir. But I'm ok trying > > without it. > > > > Who will tell Adriaan that doxygen stuff in admin will need a new home? > > But that's for another thread. > > > > -Allen > > He's already aware of it and i believe is in the process of decoupling the > doxygen stuff from the admin dir, but i could be wrong. Anyways, he's already > said that doxygen stuff wasn't going to be a part of the build system anymore > --
I just was chatting with Adriaan on #ebn a few minutes ago. We were thinking about moving the admin/doxygen build script into a new program (tentatively called kde-doxybuilder). The source would be in kdelibs/doc/api or somesuch. So this would be installed just like any other KDE app. -- Let's Keep the Political Talk Out of KDE PLEASE _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
