KDE/kdelibs

[Alexander Neundorf]

On Sunday 30 April 2006 14:34, David Faure wrote:
> On Saturday 29 April 2006 00:24, Alexander Neundorf wrote:
> > SVN commit 535237 by neundorf:
> >
> > -check where some of the results are used
> > it seems there are quite a lot of checks which aren't used anywhere
> > I moved the (seemingly) unused checks at the of the file, I guess they
> > can be removed.
>
> Right. E.g. HAVE_PUTENV makes little sense; putenv is our fallback in
> fakes.c in case setenv isn't available, but if neither of those are
> available then this must be a very strange platform indeed - and one we
> can't support anyway. If those HAVE_FOO are unused, just remove them.
>
> > Do we want modular configuration ?
>
> Yes... but maybe only up to a point. All those system header files
> (sys/types.h etc.) are very unlikely to change on a given system, so I'm
> fine with those remaining in some kind of global .h file, except that maybe
> we should rename it (config-lowlevel.h to reuse a name introduced by
> bksys?) to avoid people adding non-lowlevel things to it... Dunno.

The lowlevel in bksys meant checks for lowlevel stuff ? 
I thought it means lowlevel functions for checking stuff.
Maybe config-system.h, but actually I'd just keep the name "config.h".

> See, you can install FAM or CUPS on an existing system, so it makes sense
> to have this in separate .h files. But you can't really install
> sys/select.h or mkstemp on an existing system out of the blue...
>
> > Then we should create a kjs-config.h, a kioslave-config.h, a
> > kdecore-config.h and a kio-config.h I think.
>
> Not necessarily this way.
> The kdecore/kio split is kind of arbitrary and going to change and
> unrelated to configuration. Better have it split out by functionality
> instead, like I did with config-kdirwatch.h or config-cups.h etc. (Can we
> stick to config-foo.h instead of foo-config.h, since that's what I started
> using everywhere? ;)

I don't care. If you prefer config-foo.h, ok.

> All the mntent/fstab/mnttab/"sys/mount" stuff (i.e. everything that you
> found as "kio, kdecore") is only due to a kind of API duplication from kde3
> (KMountPoint vs the functions in kio/global.h), and Josef Wenniger told me
> he was working on merging that. Meanwhile and independently from this, we
> can move all those defines into a config-mount.h or config-kmountpoint.h
> and use them from both places right now, and in the end only KMountPoint
> will use that stuff. The benefits of modularity ;) Real modularity (based
> on functionality, not on library split).

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.

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