333271 - configure.in uses cygwin wrapper overzealously

Status: RESOLVED INVALID

(Directory :: LDAP C SDK, defect)

Description

[[e-mail]]

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.

Comment 1

[[e-mail]]

Attachment: Proposed patch

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

Obviously I'd like this to go on the Mozilla branch too.

Comment 2

[Mark Smith [:mcs]]

Reassigning to Rich (who has had his hands in the LDAP C SDK configure scripts lately).

Comment 3

[Rich Megginson]

Attachment: 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?

Comment 4

[[e-mail]]

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.

Comment 5

[Rich Megginson]

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.

Comment 6

[[e-mail]]

Ah, well SFU needs MOZ_BUILD_ROOT to be a cygwin style path, afaik.

Comment 7

[Rich Megginson]

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.

Comment 8

[[e-mail]]

All I can tell you is that it doesn't work with SFU.

Comment 9

[Rich Megginson]

So how did you get it to work on SFU?

Comment 10

[[e-mail]]

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

Comment 11

[Rich Megginson]

Can you attach your diffs to this bug?

Comment 12

[[e-mail]]

Attachment: 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

[Steffen Wilberg]

Comment on attachment 217708 [details] [diff] [review]
Proposed patch

Clearing review request since the reporter and requestee marked the bug as INVALID.