modular configuration(Re: KDE/kdelibs)

[Alexander Neundorf]

On Sunday 30 April 2006 17:29, David Faure wrote:
> On Sunday 30 April 2006 15:13, Alexander Neundorf wrote:
> > Yes, these are the two options:
> > -splitting it on functionality (like with config-acl.h)
> > or
> > -splitting it by library
> >
> > Both make sense.
> > To me it seems more natural to split by library. If you need a check in
> > kfoo, just add that check in kfoo and put the result in config-kfoo.h.
> > This would also make it easier to move directories around or to compile
> > parts independent from the rest of the module, since it will contain all
> > the configure checks it needs.
>
> I agree, but with kfoo being a functionality (e.g. acl) or a
> functionality-specific class (e.g. kdirwatch or kmountpoint), not a whole
> lib. If you move KMountPoint from kdecore to kio or vice-versa, nothing
> changes in the config-mount.h file. Whereas if it's all mixed up inside
> config-kio.h then we're back to the initial problem: not enough modularity.

Well, also modular, only different ;-)

> But I agree with you about the lowlevel stuff (from libc, so unlikely to
> change) used in N subdirs. For that part we can either keep one config.h or
> go for config-kdecore.h / config-kio.h / ... to minimize recompiles when a
> new HAVE_FOO check is needed for a library. I'm fine with a per-lib split,
> but ONLY when a per-functionality split isn't possible or doesn't make
> sense.

Hmm, not sure I understand.
E.g. there are some tests which are only used in some ioslaves. E.g. 
HAVE_SENDFILE is used only in the file ioslave. Should this stay in 
kdelibs/config.h, or be moved to kdelibs/kioslave/config-kioslave.h or to 
kdelibs/kioslave/file/config-fileioslave.h ? This would be the most local 
location. When programming, making stuff as local as possible is usually 
considered a good thing.
For the author of the file-ioslave (oops, isn't this you ?) it would probably 
be the most natural thing to add this check to 
kdelibs/kioslaves/file/CMakeLists.txt and create a config-fileioslave.h
Or let's take the fish ioslave.
It would be nice if I could simply copy kdebase/kioslave/fish/ somewhere and 
release it separately (with minor changes). For this purpose it would be nice 
if all configure checks the fish ioslave needs would be located in 
kdebase/kioslave/fish/.

This will also be true for other applications (e.g. kwin styles, maybe also 
khtml, kolorpaint, well, apps for which it makes sense to be released 
separately).
For these cases ideally all checks they need would have to be located in the 
specific subdirectory. But maybe this would lead to new problems, many config 
headers in every module, maybe multiple tests for the same thing done 
slightly differently, maybe with the same name or maybe with a different 
name, which might make debugging it harder.

I'm not sure what the best way is.
I think if application kbar needs a check, the check should be added in the 
directory of application kbar.

And I think if we have separate header files (config.h, config-mount.h), we 
should also have separate configure files (ConfigureChecks.cmake, 
ConfigureChecksMount.cmake).

Now concrete to kdelibs: 

There are a bunch of checks which are only used libltdl. If we create a 
config-libltdl.h, we need to modify the sources of libltdl. AFAIK libltdl is 
our own copy of the main version of libltdl. Is it ok to modify the sources 
or do we want to keep the changes there minimal ?

What about kdecore/malloc/ ? is this still used ? Are modifications ok ?

kdelibs/kjs: shall I add all the tests to kdelibs/kjs/global.h ?
I would then prefer renaming kjs/global.h to config-kjs.h. Is Apple somehow 
involved here ?


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