why Chromium stop using SCons for building?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

why Chromium stop using SCons for building?

Ilya Murav'jov
Hi!

 Here is the link about it:
http://www.mail-archive.com/chromium-dev@.../msg10131.html

 I do not want to start a flame about it (I really like SCons), I just
would like to know (all) reasons why SCons is not suitable for such a
project. Is it just about SCons' speed (slowness)?

Regards,
 Ilya Murav'jov

------------------------------------------------------
http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=2648776

To unsubscribe, send an e-mail to [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

Re: why Chromium stop using SCons for building?

Steven Knight
Hi Ilya--
 
 Here is the link about it:
http://www.mail-archive.com/chromium-dev@.../msg10131.html

 I do not want to start a flame about it (I really like SCons), I just
would like to know (all) reasons why SCons is not suitable for such a
project. Is it just about SCons' speed (slowness)?

Speed was a consideration, but the main thing was that the IDE is pretty central to the way the Chrome developers work, and any alternative to the native tools needed some other compelling advantage.  If the IDE integration had been better, the performance might (might) have been livable.

That particular thread came relatively late in the game, after the Chrome team started using a custom tool (GYP, similar to CMake in that it generates Visual Studio, Xcode, SCons and Make build configurations).  There's a moderate mismatch between GYP's component model and SCons that exacerbated the performance issues.

HTH,

        --SK
Reply | Threaded
Open this post in threaded view
|

Re: why Chromium stop using SCons for building?

Ilya Murav'jov
Steven Knight пишет:

> Hi Ilya--
>
>
>>  Here is the link about it:
>> http://www.mail-archive.com/chromium-dev@.../msg10131.html
>>
>>  I do not want to start a flame about it (I really like SCons), I just
>> would like to know (all) reasons why SCons is not suitable for such a
>> project. Is it just about SCons' speed (slowness)?
>>
>
> Speed was a consideration, but the main thing was that the IDE is pretty
> central to the way the Chrome developers work, and any alternative to the
> native tools needed some other compelling advantage.  If the IDE integration
> had been better, the performance might (might) have been livable.
>
> That particular thread came relatively late in the game, after the Chrome
> team started using a custom tool (GYP, similar to CMake in that it generates
> Visual Studio, Xcode, SCons and Make build configurations).  There's a
> moderate mismatch between GYP's component model and SCons that exacerbated
> the performance issues.
>

Thanks for the answer. So, one can deduce that even Google has failed to
realize somewhat universal build system for now
(http://code.google.com/p/gyp/wiki/GypLanguageSpecification#Background).

Regards,
 Ilya

------------------------------------------------------
http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=2650314

To unsubscribe, send an e-mail to [[hidden email]].
Reply | Threaded
Open this post in threaded view
|

Re: why Chromium stop using SCons for building?

Steven Knight
Thanks for the answer. So, one can deduce that even Google has failed to
realize somewhat universal build system for now
(http://code.google.com/p/gyp/wiki/GypLanguageSpecification#Background).

Yeah, basically.  You could make a pretty good argument that a real "universal build system" can't really exist in practice (if for no other reason than that if it were readily doable, some one would have already invented it!).  As it stands, all build systems seem to have their limitations and shortcomings, especially when applied outside the boundaries of the projects they were designed around.

That said, GYP isn't bad.  (Disclaimer:  I helped work on it after it became clear SCons wasn't working well for Chromium.)  GYP's component model and propagation of settings based on component dependencies work quite well (at least for Chromium, and related projects that use the Chromium code base).  The biggest drawback (IMHO) is that the build language is declarative JSON, and the support for conditionals involves two-phase delayed evaluation of lists and variables in a way that lead to really gnarly and hard-to-read nested data structures.  Doing complicated things takes a pretty thorough knowledge of how the tool works.

        --SK