On Mar 16, 2014, at 8:18 AM, Patrick Gansterer <par...@paroga.com> wrote:
> On 16.03.2014, at 16:10, Darin Adler <da...@apple.com> wrote: >> On Mar 16, 2014, at 3:01 AM, Patrick Gansterer <par...@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. >> 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. > 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! > 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. 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. — Darin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
