245288 - Build standalone JS engine using native Cygwin toolchain

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Mike McCabe]

I like to have a js engine around, for some reason, and I have a very small set
of changes ready make Makefile.ref build a 'native' Cygwin js engine.

Currently, 'make -f Makefile.ref' under Cygwin expects to find the MSVC
compiler.  These changes make Cygwin use gcc and the rest of the unix toolchain.
 I think this is the most reasonable default behavior for building the
standalone js engine under cygwin.

Other versions that can build or link in a more Windows-friendly way may also
make sense, but I don't think that requiring MSVC should be the default.

Essentially, the changes are limited to introducing a new config/Cygwin.mk that
is almost identical to config/Linux_all.mk, and modifying config.mk to point
cygwin builds to it.  No other changes needed.  The only change from
Linux_all.mk is to use 'gcc -shared' instead of 'ld -shared' to make the
library; everything else just works.

Some related bugs - I think this issue has been approached differently before:
Bug 72154 - "Can't build JS Shell with CygWin" - the fix for this was to work
around Cygwin's uname to make it more of a Windows build.
Bug 130104 - "Spidermonkey ported to Cygwin" - never committed, seems to include
changes towards building the engine as a windows DLL.

Comment 1

[Mike McCabe]

Attachment: New js/src/config/Cygwin.mk file

Comment 2

[Mike McCabe]

Attachment: Modify config.mk to use OS_CONFIG := Cygwin

Comment 3

[Mike McCabe]

Add some CCs.

Comment 4

[timeless]

this will hurt me. I tend to use make -f Makefile.ref on systems w/ the mozilla
build system and msvc but not gcc.

i should not have to replace uname (that's likely hazardous to my build mozilla
build system).

how about checking CC or an equivalent env var?

Comment 5

[Mike McCabe]

How about something from vcvars.bat - is there some well-known env variable that
is set in environments with msvc?

Comment 6

[timeless]

MSVCDir was suggested by a colleague. Unfortunately the "Microsoft Visual C++ 
Toolkit 2003" does not set *any* interesting variables, just PATH, INCLUDE and 
LIB.

If you're going to fish through a generic environment, I'd suggest checking for 
various compilers in PATH and picking the one that comes first.

otherwise, make people set CC=... if they want something specific (and please 
default to cl ;-). - Note that openwatcom includes a cl driver...

Comment 7

[Mike McCabe]

Attachment: Revised patch

Hm, I'd still like to have the 'out of the box' build work under Cygwin if
possible, without the need for setting anything special in the environment... I
know I've hit this issue several times now over the years, and I forget how to
get around it each time :)

Would this work? -
Under Cygwin, use the MSVC build if 'cl' is in the path, otherwise use the
Cygwin build; override with USE_CYGWIN.  Patch attached.  An alternative is to
check CC...

(I'm not sure what to do with openwatcom - but if it puts a 'cl' in the path,
it should keep the current behavior.)

Comment 8

[timeless]

looks fine, i'll see about testing eventually.

Comment 9

[Serge Gautherie (:sgautherie)]

Is this still wanted, given bug 462361?

Comment 10

[Benjamin Smedberg]

This is entirely unrelated to bug 462361, but given that Makefile.ref is gone and we don't really care about cygwin support here, I'll mark this INCO.