[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Heads-up: kdeutils is moving to git
From:       Nicolás_Alvarez <nicolas.alvarez () gmail ! com>
Date:       2011-08-21 4:13:26
Message-ID: CANPC-tuybi6Lh5TU0tSYas3joph5bpZa13qEP1ZJ0yffViYUWg () mail ! gmail ! com
[Download RAW message or body]

On 8/21/11, Aaron J. Seigo <aseigo@kde.org> wrote:
> On Sunday, August 21, 2011 00:10:07 Nicolas Alvarez wrote:
>> Superbuild is unrelated and orthogonal to the code in kdeutils to
>> allow building as a single module.
>
> yes, and that's the challenge here: it takes ~10 seconds to put a bunch of
> "add_subdirectory" calls into a CMakeLists.txt file. the issue is having to
> manually keep up a bunch of git repositories individually, from cloning to
> pulling, ensuring they are in the correct hierarchy initially on disk, etc.

Correct, because that's not the problem it's supposed to solve. The
CMakeLists.txt with add_subdirectory lines is just if someone wants to
make a tarball that works just like the old kdeutils.tar before the
split, ie. "recreate the 'whole module' build". For *that* task, I
think superbuild is the wrong tool. For example, if Dirk makes a
monolithic kdeutils tarball, he should use this instead of superbuild.

I see superbuild as a third tool in the same category as kdesrc-build
and build-tool, cloning and pulling a bunch of git repositories,
ensuring they are in the correct hierarchy on disk, etc. And it's
probably a good task for that job.

But this is the release-team list, so here I'm talking about the
release, not the developers' workflow. Jeremy said, "If Dirk is going
to use superbuild to do the release tarballs..."; *that* is what I
think is a bad idea.

-- 
Nicolas
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]