[Bf-committers] Removing Build Systems

Campbell Barton ideasman42 at gmail.com
Mon Apr 13 01:28:03 CEST 2009


On Sun, Apr 12, 2009 at 3:22 PM, GSR <gsr.b3d at infernal-iceberg.com> wrote:
> Hi,
> brecht at blender.org (2009-04-12 at 1647.42 +0200):
>> We currently have 4 build systems being maintained: Makefiles, SCons,
>> CMake and MSVC. Making changes for 2.5 development and doing merges
>> for all 4 has gotten quite tedious and I've lost days fiddling with
>> all these build systems. Further it seems that compilation breaks
>> often because of lacking build system updates, which again takes time
>> working with people in #blendercoders to get things building again.
>
> Interesting issue about getting things done.
>
> Instead going mad with changes, just document in commit log what is
> needed and let others do it. It will break the build in some systems
> for a couple of days (we do not have autobuilders so...), but OTOH it
> should allow proper and efficient response once someone has time to
> look at the issue. Guessing what has changed is another waste of time,
> just like is trying to fiddle with all them, just different persons
> wasting time.
>
> And the other day I joked about GIT, but a more distributed work mode
> (git, hg, whatever... I am not talking about one but the concept)
> could help with time waster things. Or not, as it would mean learning
> another system and everybody administrating "own copy". SVN is still
> used below what it can do, anyway.
>
> There are plenty of tools and options, but they have to be used and
> hops reduced so more people can contribute more effectively (original
> CMake implementor vanished, hint or coincidence?).
>
> But back to just build systems:
>
> [...]
>> SCons I think we should keep because it is well maintained and easy to
>> use. CMake can generate native project files and is much faster than
>> SCons on older systems. So we can keep both of these I suppose, though
>> one would be ideal.
>
> CMake still needs to be in the same level of the others. Last time I
> checked it had issues with add-on libs like FFMPEG. Which for me seems
> to be the other biggest issue, we are not maintaining 4 systems for
> Blender, we are maintaining four and hacking build systems in a
> handful libs; and even shipping precompiled versions too, without
> checking at build time (see issues in last weeks about lib/). So that
> makes three extras compared to most other projects (that do not have
> many systems, add systems for libs or build libs).
>
> For now, I will just keep on digging around Makefiles, they seem to be
> a bit alive yet. If anybody needs help with those, just contact me.
>
> GSR

Hey Brecht, was that a rant? :-)
I'm surprised after that there could be any argument!, well put.

Best just get Ton off Makefiles and then let the GSR and the community maintain.

GSR- is it was only a group of devs building blender Id agree with
you, but a lot technical users build blender too.
At the moment it seems 1-3 people maintain search build system, which
keeps them 'good enough'. but still shoddy in areas the maintainer
cant test well.

Something I really like about blender is how users build blender and
often complain when stuff breaks,
But when this is build system related it gets tedious and difficult
when your not using the same one as Brecht said. - And not time spent
productively.

- Though now its pretty much at the point where we tell new users only
to use scons so its not that bad, just that they sometimes use make or
cmake at first.

+1 strongly in favor of dropping Makefiles, (and MSVC project files
though I have not had anything to-do with these, it seems CMake can
replace them?).

-- 
- Campbell


More information about the Bf-committers mailing list