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

[Patrick Gansterer]

On 16.03.2014, at 16:28, Darin Adler <darin at apple.com> wrote:

> 
> 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.
> 
> Maybe we can do this even more simply. Invoke gnu make as a separate step before CMake kicks in, or make this just one add_custom_command.
> 
> We should not think of DerivedSources.make as a set of custom per-file build commands, otherwise the connection between the two will be really complicated.

Maybe I should have be more precise:
You need a add_custom_command() for every "make all" on the different DerivedSources.make. (like it's implemented in the Windows build system)

>>> 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, …).
> 
> Could you be more concrete about specific benefits for the things in DerivedSources.make? Like an example of some build rule that benefits from better platform abstraction or dependency tracking?
> 
> Are there examples where the CMake clone of DerivedSources.make is much simpler for some build rules?
> 
> I’m not sure that platform abstraction has much value for the platform-independent derived sources build rules. I’m also not sure we get significantly better dependency tracking for the rules in that file. I’m sure both of those are great for other parts of the build process.

The big point is Windows. ATM we require a complete cygwin installation (with all the connected problems) for building on Windows. The "CMake only" Windows ports don't need that. They work with the "native" Win32 versions of all tools (bison, gperf, perl, python, ...).
If we move to make only, we introduce this dependency for the CMake ports building on Windows (WinCE + GTK).
In general I don't think that the CMake rules will be simpler, more or less the same as for make.
The dependency tracking is interesting for use in an IDE, where CMake provides then the possibility to e.g. to a regeneration of only one idl file. For sure not the most important use case to support, but very handy features if you need it sometime.

>> For sure it's doable, but I'm not a big fan of kicking out CMake in favor of simple make.
> 
> Yes, I can tell you are really attached to it!

Yes, since it solved many platform-specific problems for me. This worked only by using it as the basis for the whole build system and not only for some parts. But maybe I'm already too attached to it. :-)

>> 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?
> 
> I understand your question, and I believe there is an answer. We tried CMake here at Apple for the Xcode project a while back and had many, many problems turning it into something we could use.

Please don't get me wrong (I don't want to complain!), but it's some kind of sad that this happens without a public discussion. E.g. I never got any feedback on my patches I created to address the points Apple people brought up as their CMake requirements (e.g. WTF, JSC, WebCore and WebKit must be built separate).

> But this project, removing all the duplicate make steps, is far, far smaller and has immediate benefits. We have not been having problems with DerivedSources.make over the last few years.

If you work on UNIX only I can agree. Setting up the build environment for WebKit on Windows is not the most straight forward thing. But the kind of Windows support this more a political decision. ;-)


IMHO it's sad to see a step away from CMake platform abstraction, but if it's vitale for the project I can life with it too. Since the code is still in the SVN history, there should be no big problem in getting back to it once again.

But from the technical point of getting it working, it's not such a big deal if you go with a solution like in the Windows port (own project for generating derived sources with Makefiles + project level dependencies).

--
Patrick