[Bf-committers] Keep SCons relevant to CMake

Campbell Barton ideasman42 at gmail.com
Mon Dec 22 11:56:14 CET 2014


On Mon, Dec 22, 2014 at 9:57 AM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
> Hey,
>
> This rant is caused by the following change:
> https://developer.blender.org/rBe67fd7a (Cambo, sorry, this commit just
> happened to be the most recent which demonstrates the issue we're having).
>
> Well, it was fair enough change to split appdir routines into dedicated
> file keeping path utils small and nice. And was fair enough change to fix
> CMake compilation. But hey, where's the change to SCons?!
>
> I would ask everyone to pay more attention on making sure changes to either
> of SCons or CMake build systems are also ported to another system. I
> wouldn't expect it to be huge overhead to do such a tweaks for both systems.
>
> And yes, all the rants about "hey, SCons is stupid and CMake is just much
> nicer" could be send directly to /dev/null. I do not care about such a
> statements for as long SCons continues to be officially supported and used
> for release builds process.
>
> End of rant, now let's get back to 2.73 release work.
>
> --
> With best regards, Sergey Sharybin

Apart from my response (to being made an example of :) )

Sergey's point of CMake/SCons being kept in sync (in general), is
important. Sometimes reading over the build flags and comparing it
seems as if devs haphazardly (over the years) tweak the
compiler/linking flags in without much explanation in commit logs and
cmake/scons configurations diverge (Noticed this with Linux include
flags & msvc build flags).
Trying to make sense of these changes after-the-fact isnt fun.


More information about the Bf-committers mailing list