KDE 4 modules structure (again)

[Dominique Devriese]

Thiago Macieira writes:

> Dominique Devriese wrote:
>>> 5. Increases the clean build time --- every single module needs to
>>> have configure genederate, configure run; doing this per-module is
>>> quicker than doing this per-application
>>
>> This is partly true, but its effects are not so bad because: 1 The
>> amount of work that configure needs to do per-app will decrease.

> I don't follow you here. What do you mean?

> From what I understand, the amount of work would _increase_, not
> decrease. When you have 60 apps and 10 modules, configure is run 10
> times, but on average each app corresponds to one sixth of that. If
> you have 60 configures, then each app's individual part will have
> increased 500%.

Well, what I meant is that, because the generated configure scripts
will be somewhat shorter the apps' individual parts increase can be
limited to, say, 400%.

>> 2 The time taken by configure is small compared to the time taken
>> for building the source.

> True, but if you multiply the configure time by 5-10 and if you
> compare the configure time to the build time of some of the smaller
> apps, it'll be noticeable.

Noticeable yes, an insurmountable problem: imho not.  By the way, I
think there is quite some potential left to optimize the configure
scripts...

> Isn't there a way of making it a recursive structure? For instance,
> checking out "kdebase" gets you all the apps and one configure for
> all of them, but checking out "kdebase/kicker" gets you kicker
> alone, with its own configure, which you could place side by site to
> "kdebase/kdm" in order to make packages and/or release tarballs.

I like this idea.  It has the potential to combine the advantages of
both approaches.  I think the technical problems with it ( configure
checks that are needed by more than one app in e.g. kdebase ) can be
fixed by moving them into a autoconf macro, and then making judicious
use of AC_REQUIRE.

cheers
domi