configure.in uses cygwin wrapper overzealously

RESOLVED INVALID

Status

RESOLVED INVALID
13 years ago
11 years ago

People

(Reporter: neil, Assigned: richm)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

13 years ago
I have an SFU build that I like to keep up-to-date. You can look at the SFU bug if you want to see all the patches that I need to get it to work, but this bug only relates to a couple of general issues that I faced when the client branch that Mozilla has started pulling recently changed.
One problem that SFU has is that you can't wrap the wrapper. I disovered this because the new branch uses the wrapper in a different way, so I didn't have to add it in the place I had to before. In fact I had ended up with triple wrapping! However while tracking this down I still found one place where you were applying the wrapper twice.
The other issue was that you actually forced the use of the cygwin wrapper (I need to use a different wrapper for SFU because I can't figure out how to change its /dev/fs mount). I guess this error must have crept in when the MSYS changes were ported between the branches.
(Reporter)

Comment 1

13 years ago
Created attachment 217708 [details] [diff] [review]
Proposed patch

This fixes it in the style of nsprpub/configure.in

Obviously I'd like this to go on the Mozilla branch too.
Attachment #217708 - Flags: review?

Comment 2

13 years ago
Reassigning to Rich (who has had his hands in the LDAP C SDK configure scripts lately).
Assignee: mcs → richm
(Assignee)

Comment 3

13 years ago
Created attachment 218927 [details]
Get rid of cygwin-wrapper completely

I tried a build with this, using cygwin + the MSVC compilers, and it worked fine.  So I guess we do not need cygwin-wrapper anymore.  Can you verify that my changes work for you?
(Reporter)

Comment 4

13 years ago
No they don't. I'm building the LDAP SDK as part of Mozilla, and I'm seeing absolute cygwin paths used everywhere e.g. the srcdir and dist in Makefile.
(Assignee)

Comment 5

13 years ago
Which Makefile?  mozilla/directory/c-sdk/Makefile?

For mozilla client builds (--with-mozilla), the ldap part should just use whatever paths were passed in, with --with-dist-prefix.  This is what sets DIST in the Makefiles (see config/autoconf.mk).  I'm not sure where the cygwin style paths are coming from.  configure.in has some logic to convert nspr and nss paths given by the user into cygwin paths, but that should only happen on cygwin shells:
dnl ========================================================
dnl If using cygwin (or another Windows shell that uses unix
dnl style paths by default - mingw?) and using MSVC, we need
dnl to convert the include and lib paths to the more MSVC
dnl friendly format - it's easier and faster to do it here
dnl than in cygwin-wrapper
dnl ========================================================

dnl add other runtime environments that use unix style paths
dnl *-cygwin*|*-mingw*|*-msvc*|*-mks*)
case "$target" in
*-cygwin*) USE_WINDOWS_PATHS=1 ;;
esac

if test -n "$_WIN32_MSVC" -a -n "$USE_WINDOWS_PATHS" ; then
    if test -n "$NSPR_CFLAGS" -a -z "$SKIP_CYGWIN_FIXUP" ; then
        path=`echo $NSPR_CFLAGS | sed -e 's/^-I//'`
        path=`cygpath -m $path`
        NSPR_CFLAGS="/I$path"
    fi
.....
If building with --with-mozilla, SKIP_CYGWIN_FIXUP is set, meaning that we just want to use the paths given by the client build and we don't want to change them.
(Reporter)

Comment 6

13 years ago
Ah, well SFU needs MOZ_BUILD_ROOT to be a cygwin style path, afaik.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
(Assignee)

Comment 7

13 years ago
So the current code works fine?  Does it also work with my changes?  If so, I'd like to check in my changes - I'd like to eliminate the use of cygwin-wrapper if possible.  I see no reason to use it if we can fix the paths during configure.
(Reporter)

Comment 8

13 years ago
All I can tell you is that it doesn't work with SFU.
(Assignee)

Comment 9

13 years ago
So how did you get it to work on SFU?
(Reporter)

Comment 10

13 years ago
The other changes I have in my SFU build are:
* Addition of SFU detection to configure.in
* Detection of .exe suffixes (not sure if that was because I misconfigured SFU)
* Tweaked the cygwin-wrapper to work with SFU
* Changed $(win_srcdir) to $(srcdir) in two makefiles
(Assignee)

Comment 11

13 years ago
Can you attach your diffs to this bug?
(Reporter)

Comment 12

13 years ago
Created attachment 220337 [details] [diff] [review]
SFU build patch

Note: this patch does not suffice to build using SFU; there is a bug in autoconf that even with AC_EXEEXT it doesn't actually apply the extension when it should. SFU is very strict about launching Windows exes so you must either launch the program using the bare name (which will be searched for using the PATH_WINDOWS variable) or specify the full SFU (but not Windows) path including extension.

Comment 13

11 years ago
Comment on attachment 217708 [details] [diff] [review]
Proposed patch

Clearing review request since the reporter and requestee marked the bug as INVALID.
Attachment #217708 - Flags: review?
You need to log in before you can comment on or make changes to this bug.