Doxy Generation (Was: [FEATURE REQUEST] CMake and Colors)

Allen Winter winter at kde.org
Mon Apr 3 01:58:10 CEST 2006


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


More information about the Kde-buildsystem mailing list