202058 - Compile source files with absolute pathnames to ease debugging

Status: RESOLVED FIXED

(NSS :: Build, defect, P1)

Description

[Julien Pierre]

This bug is the NSS counterpart bug to bug 105271 which is for NSPR . I'm
breaking up the bug because that bug has become too large.

In the following environments, the debugger does not automatically locate source
files. This occurs whether NSS is built standalone or as part of another product
(eg. mozilla). The debugger prompts the developer to manually locate the files
under :

- All Windows plaforms with Microsoft compilers and Microsoft debugger,
including Cygwin & MKS build environments
- OS/2 with IBM VACPP compiler, using IBM debuggers
- OS/2 with gcc compiler, using IBM debuggers

The fix is to pass an absolute path to the source file to the compiler.

Comment 1

[Julien Pierre]

Taking bug.

Comment 2

[Julien Pierre]

Attachment: Patch to compile with absolute pathname where needed

Comment 3

[jhp (no longer active)]

Comment on attachment 120543 [details] [diff] [review]
Patch to compile with absolute pathname where needed

I assume you built and debugged successfully on VACPP and GCC, standalone and
full browser build?  If so, and with the comments I put in bug 105271,
r=pedemont

Comment 4

[Julien Pierre]

On OS/2 I did standalone builds of NSS only, both with GCC & VACPP. No full
browser builds. My current OS/2 box at the office is way too slow (6 hours + for
a browser build) and low on disk space. I'm getting a refresh soon so this
should be less of a problem. I would appreciate if you could plug in this fix
into one of your browser trees and see if it still works.

On Windows I also did standalone NSS builds only, with both MKS & Cygwin. I may
run a browser build later today.

Comment 5

[Wan-Teh Chang]

Comment on attachment 120543 [details] [diff] [review]
Patch to compile with absolute pathname where needed

>+ifeq (,$(filter-out WIN%,$(OS_TARGET)))
>+ifdef USE_NT_C_SYNTAX

The ifdef USE_NT_C_SYNTAX here shoule be removed.

Use the call function only if NEED_ABSOLUTE_PATH
is defined.  This avoid the requirement of gmake
3.79.1 on all platforms.

Comment 6

[Julien Pierre]

Wan-Teh,

The ifdef USE_NT_C_SYNTAX is present to trigger the absolute path on Windows
platform with the Microsoft compilers only. I do not know whether the gcc
compiler on Win32 requires absolute pathnames or not. Without that information,
I chose to leave it alone, and therefore I have to make this test.

I will make the other change you requested to avoid the need for gmake 3.79 on
all platforms.

Comment 7

[Julien Pierre]

Attachment: Don't require gmake 3.79 on Unix platforms

Comment 8

[Wan-Teh Chang]

Comment on attachment 120768 [details] [diff] [review]
Don't require gmake 3.79 on Unix platforms

r=wtc.

You can check in the patch as is.  Some suggestions.

1. I agree with Javier that the nested if-else statements
should be avoided whenever possible.  You can use "endif"
instead of "else" after the following.

>+ifeq (,$(filter-out OS2%,$(OS_TARGET)))
>+NEED_ABSOLUTE_PATH := 1
>+PWD := $(shell pwd)

2. It is better to explicitly test NS_USE_GCC than to
test USE_NT_C_SYNTAX.  (I was planning to add the code to
handle gcc after I land the Win32 gcc patch.)

3. The else part of the following can be deleted.

>+ifdef NEED_ABSOLUTE_PATH
>+abspath = $(if $(findstring :,$(1)),$(1),$(if $(filter /%,$(1)),$(1),$(PWD)/$(1)))
>+else
>+abspath = $(1)
>+endif

Comment 9

[Julien Pierre]

Wan-Teh,

1. I fixed the nested ifs .

2. I didn't realize the code to build NSS with gcc on Win32 hadn't landed. I now
see why you made the comment earlier about the test for USE_NT_C_SYNTAX being
unnecessary - it is currently always set on Win32. I'll put a check for
NS_USE_GCC instead .

3. I'd like to keep the else statement for the days when all platforms have
upgraded to gmake 3.79 or later, and we can remove the checks for
NEED_ABSOLUTE_PATH and simply use $(call in the rules where needed .

Comment 10

[Julien Pierre]

Attachment: Patch updat

1. Remove nested ifs

2. change check for gcc on Win32

Comment 11

[Julien Pierre]

Checked in to the tip.

/cvsroot/mozilla/security/coreconf/rules.mk,v  <--  rules.mk
new revision: 1.51; previous revision: 1.50
done

and NSS_3_8_BRANCH .

Checking in rules.mk;
/cvsroot/mozilla/security/coreconf/rules.mk,v  <--  rules.mk
new revision: 1.50.2.1; previous revision: 1.50
done

Comment 12

[Julien Pierre]

Also moved NSS_CLIENT_TAG . I'll be watching the mozilla tinderbox tonight.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

coreconf/rules.mk, rev 1.51 (and later) now generates lots of warnings 
when I build NSS.  It spits out hundreds of copies of this error message:

SHMSDOS: cygpath: The system cannot find the file specified.

The code apparently now assumes that NSS is built with cygwin on windows.  
NSS may be built with cygwin when built as part of mozilla, but NSS may 
be built with other unix-like shell packages when it is built "stand alone".  

The code that assumes the use of cygwin is:

ifeq (,$(filter-out WIN%,$(OS_TARGET)))
ifndef NS_USE_GCC
NEED_ABSOLUTE_PATH := 1
ifeq (,$(findstring ;,$(PATH)))
PWD :=  $(subst \,/,$(shell cygpath -w `pwd`))

Other unix-like shells for windows besides cygwin also use semi-colon as
a path separation, but they do not have a cygpath command. 
This is P1.  It impacts the build. 

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

That analysis in comment 13 is obvious flawed, sorry.
Have we changed the version of gmake required to build NSS stand-alone?
I think we're still distributing 3.74, and that's what I'm using.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

I see that wintools.zip has been updated to include a newer gmake.
<emily latella> Never Mind. </emily latella>

Comment 16

[Wan-Teh Chang]

Nelson,

Sorry, I neglected to notify the NSS developers of this
new requirement.  NSPR and NSS now require gmake 3.79.1
with either MKS Toolkit or Cygwin tools on Windows.
(Note: different builds of gmake 3.79.1 are needed for
MKS and Cygwin.  For Cygwin you should use Cygwin's own
make.)

Do not use Netscape's Win32 port of gmake 3.74 and our
homegrown shmsdos to build the NSS TIP now.

By the way, the makefile fragment

ifeq (,$(findstring ;,$(PATH)))
PWD :=  $(subst \,/,$(shell cygpath -w `pwd`))

does not work under gmake 3.74 (maybe 3.76.1 too) and
causes MKS and shmsdos to be identified as Cygwin, hence
the confusing build failure.