configure.in in nsprpub sets a wrong includedir

RESOLVED INVALID

Status

defect
RESOLVED INVALID
12 years ago
12 years ago

People

(Reporter: tiagosh, Assigned: wtc)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080208 Mandriva/2.0.0.12-4mdv2008.1 (2008.1) Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080208 Mandriva/2.0.0.12-4mdv2008.1 (2008.1) Firefox/2.0.0.12

when you run "./configure --prefix=/usr --includedir=/usr/include", "nspr-config --cflags" reports the wrong directory.


Reproducible: Always

Steps to Reproduce:
1. cd nsprpub
2. ./configure --prefix=/usr --includedir=/usr/include
3. make
4. config/nspr-config --cflags
Actual Results:  
-I/usr/include

Expected Results:  
-I/usr/include/nspr

the following patch should fix this bug.

--- configure.in~       2008-03-07 17:50:49.000000000 -0300
+++ configure.in        2008-03-07 17:53:49.000000000 -0300
@@ -133,7 +133,7 @@
 dist_bindir='${dist_prefix}/bin'
 dist_includedir='${dist_prefix}/include/nspr'
 dist_libdir='${dist_prefix}/lib'
-if test "${includedir}" = '${prefix}/include'; then
+if test "${includedir}" = "${prefix}/include"; then
     includedir='${prefix}/include/nspr'
 fi
Assignee: nobody → wtc
Component: Build Config → NSPR
Product: Firefox → NSPR
QA Contact: build.config → nspr
Version: unspecified → other
Assignee

Comment 1

12 years ago
cls, could you take a look at this?  I'm not sure what's the intended behavior here.

Comment 2

12 years ago
The intended behavior was to only add '/nspr' to the $includedir if --includedir was not provided as anyone could manually add /nspr themselves if they decided to override includedir.  This was to be able to support putting the headers in an include dir that isn't nspr specific (ie. /usr/include/seamonkey-3.14159/) or with a version suffix (ie. /usr/include/nspr-4.6/). I've seen --includedir behave both ways so I don't consider it a bug but I can see how it could be interpreted as such.
Assignee

Comment 3

12 years ago
cls, thanks for the clarification.

Tiago, thanks for the bug report and patch.  This is a
little confusing, but it is working as intended.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.