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

Patrick Gansterer paroga at paroga.com
Sun Mar 16 11:06:07 PDT 2014

On 16.03.2014, at 18:50, Filip Pizlo <fpizlo at apple.com> wrote:

> This discussion about DerivedSources is too abstract for me. 
> If the only thing that DerivedSources.make looks for is python, perl, and ruby, then there has got to be a way for cmake to pass arguments to DerivedSources to tell it where to find those binaries.  

DerivedSources.make depends heavily on UNIX command line tools (cat, sed, sort, ...) which are not part of a clean Windows installation and don't provide Windows like installers.
The point is if we want to make cygwin (with all of its pro and cons) a requirement. At the moment the minimal requirements for building on Windows are GNU Win32 GPerf, Win flex-bision, Perl, Python and Ruby (which provide nice native Windows installers).
Bugs like 48166 suggest that also not all Apple folks are happy with cygwin.

>> On Mar 16, 2014, at 9:59 AM, Patrick Gansterer <paroga at paroga.com> wrote:
>>> On 16.03.2014, at 17:37, Darin Adler <darin at apple.com> wrote:
>>>> On Mar 16, 2014, at 9:12 AM, Patrick Gansterer <paroga at paroga.com> wrote:
>>>> The big point is Windows.
>>> So the core issue isn’t really about CMake at all! It’s that the base Windows tool set doesn’t include GNU make or an equivalent. How different is this from other dependencies we have on Windows such as perl and python? Is it a lot easier to get CMake than to get GNU make?
>> It's not directly about the GNU make, since it can be replace more or less easy with nmake (wich does not use more than one core). It's more about all of other UNIX commands (e.g. cat), which make the Makefile depend on cygwin.
>> Perl/Python have native Win32 installations, which will be found by CMake during the configure step when installed at the usual path.
>> Maybe CMake is not much easier to get and install, but it behaves more like a usual Windows executable IMHO.
>> See e.g. [1] for some old bug about "Stop using Cygwin".
>>> I wonder if there are any options for improving the Windows situation that don’t involve moving both Apple ports over to CMake.
>> Maybe we can move only the Windows port to CMake? Since it has not such strong requirements on the build process as the Mac port (AFAIK from previous discussions).
>>> Could also wait to hear from experts like Mark Rowe about what the latest Apple experiences with CMake were.
>> [1] https://bugs.webkit.org/show_bug.cgi?id=48166


More information about the webkit-dev mailing list