[webkit-dev] DerivedSources.make: Another try?
paroga at paroga.com
Wed Mar 19 09:56:27 PDT 2014
On 19.03.2014, at 17:35, Brent Fulgham <bfulgham at apple.com> wrote:
> Hi All,
> I’m arriving to this conversation a bit late, but had a few comments:
> On Mar 16, 2014, at 11:06 AM, Patrick Gansterer <paroga at paroga.com> wrote:
>> 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.
> To paraphrase Churchill, Cygwin is the worst form of UNIX abstraction, except for all the others. We find that it is a whole lot easier to get a Windows build system up and running using Cygwin than trying to piece together a set of disparate GNU tools built and hosted by different parties.
I don't agree that cygwin is as worse as native UNIX. If you do not follow a specific workflow all the time, there are many problems if you switch between cygwin and non-cygwin on Windows (e.g. line endings). If your machine is for "WebKit development only", then it might not be a big point for you, but if you have to switch between different projects all the time (which have different dependencies on tools) you will feel the difference of having only "one native" systems.
> I would not want to move from a system where I can direct people to download and run our Cygwin installer, to one where I have to point out a dozen different GNU Win32 packages to manually install and setup.
You need exactly two installations for the used GNU tools: GPerf  and Win flex-bison .
Stuff like Perl, Python, Ruby is likely to be installed on a developer machine anyway.
> I would be much more interested in a system where we did not need these external tools. For example, driving the entire build system through just CMake with Perl or Python (or Ruby) would be interesting.
A first step is to start deducing the amount of the tools we use. E.g. Darin removed some usage of cat  already.
> Unfortunately, we still have strong need for a number of UNIX-y tools, such as Flex, Bison, and GPerf. This is a common problem for all projects I am aware of that involve language implementations.
More information about the webkit-dev