[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    Re: [webkit-dev] DerivedSources.make: Another try?
From:       Patrick Gansterer <paroga () paroga ! com>
Date:       2014-03-19 16:56:27
Message-ID: 9B5F18E7-529E-4547-AA18-C0006EC89936 () paroga ! com
[Download RAW message or body]


On 19.03.2014, at 17:35, Brent Fulgham <bfulgham@apple.com> wrote:

> Hi All,
> =

> I=92m arriving to this conversation a bit late, but had a few comments:
> =

> On Mar 16, 2014, at 11:06 AM, Patrick Gansterer <paroga@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 p=
rovide 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 cyg=
win.
> =

> To paraphrase Churchill, Cygwin is the worst form of UNIX abstraction, ex=
cept for all the others. We find that it is a whole lot easier to get a Win=
dows 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 bet=
ween 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 h=
ave 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 downl=
oad 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 [1] and Wi=
n flex-bison [2].
Stuff like Perl, Python, Ruby is likely to be installed on a developer mach=
ine anyway.

> I would be much more interested in a system where we did not need these e=
xternal tools. For example, driving the entire build system through just CM=
ake 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. Dari=
n removed some usage of cat [3] already.

> Unfortunately, we still have strong need for a number of UNIX-y tools, su=
ch as Flex, Bison, and GPerf. This is a common problem for all projects I a=
m aware of that involve language implementations.

[1] http://gnuwin32.sourceforge.net/downlinks/gperf.php
[2] http://sourceforge.net/projects/winflexbison/files/latest/download
[3] https://trac.webkit.org/changeset/165705

--
Patrick

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]