On 16.03.2014, at 18:50, Filip Pizlo <[email protected]> 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 <[email protected]> wrote: >> >>> On 16.03.2014, at 17:37, Darin Adler <[email protected]> wrote: >>> >>>> On Mar 16, 2014, at 9:12 AM, Patrick Gansterer <[email protected]> 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 -- Patrick _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
