[webkit-dev] DerivedSources.make: Another try?

[Maciej Stachowiak]

On Mar 16, 2014, at 8:18 AM, Patrick Gansterer <paroga at paroga.com> wrote:

> On 16.03.2014, at 16:10, Darin Adler <darin at apple.com> wrote:
>> On Mar 16, 2014, at 3:01 AM, Patrick Gansterer <paroga at paroga.com> wrote:
>> 
>>> a) Invoke make on DerivedSources.make and add a lot of custom target for that to CMake
>> 
>> I’d like to see what this would look like before deciding it’s a bad idea.
> 
> In the easiest case it's a simple add_custom_command() in CMake for every "make <target>" call. 
> 
>> I don’t know what “a lot of custom targets” means and I’d like to see what that would be like; we should simply invoke make unconditionally on DerivedSources.make before doing the rest of CMake.
> 
> This will remove all benefits CMake provides over simple make (platform abstraction, better dependency tracking, ...). For sure it's doable, but I'm not a big fan of kicking out CMake in favor of simple make.

It seems unlikely to me it would remove those benefits. The generated sources produced by DerivedSources.make have little need for platform abstraction. And DerivedSources.make already has correct dependency tracking. There are almost certainly ways to make a CMake-based build use DerivedSources.make and have all of its own dependencies correct too. One is to invoke make first, unconditionally, perhaps with a script. There are probably others.

> 
> So once again the question: What are the blockers (beside that someone has to do the work) for migrating the remaining build systems to CMake?

Using DerivedSources.make for all builds is much easier than converting all builds to CMake (something that I agree is reasonable eventually but was hard when we tried it). Right now, adding new kinds of derived sources is extremely difficult, because you have to figure out how to make custom build rules for multiple build systems. It's much harder than adding new vanilla sources.

Regards,
Maciej