318149 - Clean up configure.in

Status: RESOLVED FIXED

(Directory :: LDAP C SDK, defect)

Description

[cls]

LDAP's configure.in contains some unnecessary variable references from when it was branched from NSPR's configure.in.  For clarity, the unnecessary code should be removed.

Comment 1

[cls]

Attachment: v1.0 (checked in)

On this first pass, I've removed all of the variables that only appear in configure.in/autoconf.mk.in and are not used by any of the ldap makefiles:

--enable-boehm
AIX_LINK_OPTS
COMPILER_TAG
CPU_ARCH_TAG
GC_LEAK_DETECTOR
IMPL_STRATEGY
MDCPUCFG_H
OBJDIR_SUFFIX
OBJDIR_TAG
OS_CONFIG
NSPR_MODNAME
PR_MD_ARCH_DIR
PR_MD_ASFILES
PR_MD_CSRCS
RELEASE_OBJDIR_NAME

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 204553 [details] [diff] [review]
v1.0 (checked in)

r=dmose

Comment 3

[cls]

Is the non-autoconf build system still supported?  I noticed that the old Makefiles have been removed but the ifdefs still remain the the common .mk files.  Also, do we need the individual platform .mk files in directory/c-sdk/config/ ?

Comment 4

[Mark Smith [:mcs]]

(In reply to comment #3)
> Is the non-autoconf build system still supported?  I noticed that the old
> Makefiles have been removed but the ifdefs still remain the the common .mk
> files.

Some consumers of the LDAP code still use a non-autoconf build process.  But most of the make files used are named Makefile.client, not Makefile.


> ... Also, do we need the individual platform .mk files in
> directory/c-sdk/config/ ?

I am fairly sure these are still used by the non-autoconf build system.

I added Rich Megginson to the CC for this bug.  Rich, does the Fedora/Red Hat DS project use the non-autoconf build system?

Comment 5

[Rich Megginson]

We use the autoconf build method - see http://directory.fedora.redhat.com/Building

In the very near future, we will be cleaning up the build, making it more modular with respect to RPMs and other packaging formats, making autoconf work more smoothly, etc.

Comment 6

[Rich Megginson]

Hmm - looks like removing RELEASE_OBJDIR_NAME breaks the build - it can't find nspr.h.
I may need to add this back, or figure out another method to find nspr.h if building "in-tree" e.g. if you checkout and build in
mozilla/directory/c-sdk
and have also checked out and built nspr and nss from source under mozilla/nsprpub and mozilla/security, the build by default expects to find nspr.h in
mozilla/dist/RELEASE_OBJDIR_NAME/include
I'm working on this right now, so I'll fix it.

Chris, can you reassign this bug to me?  Thanks.

Comment 7

[cls]

Rich, I don't see how re-adding RELEASE_OBJDIR_NAME would fix the problem.  By default, NSPR puts its generated files under mozilla/nsprpub/dist when building inside the source tree using `cd nsprpub && ./configure --prefix=/foo`.  To make NSPR & LDAP use the same dist directory, you have to give one (or both) of them the --with-dist-prefix=/path/mozilla/dist .  I'm not sure where the standalone NSS expects to find the respective headers.

Comment 8

[Rich Megginson]

Ah, I see.  We don't use the --prefix or --with-dist-prefix arguments - we just use the default location that NSPR puts the files in.  So perhaps the right answer is to change the build instructions to use --prefix or --with-dist-prefix.

Comment 9

[Rich Megginson]

For in-tree builds of the standalone ldap c sdk, we build nspr and nss in-tree using the build instructions here - http://www.mozilla.org/projects/security/pki/nss/nss-3.9/nss-3.9-build.html - Are there different build instructions we should be using?  Is there some way to do
cd mozilla/security/nss ; make NSPR_PREFIX=/foo nss_build_all
?

Comment 10

[Rich Megginson]

There is a --with-nspr-prefix configure argument, but it looks like it just uses that to find the path to nspr-config, which it then uses to find the lib and inc paths.  If you're building in-tree, there is no nspr-config.
I'm going to add logic to auto-detect nspr and nss using nspr-config, pkg-config, and looking for mozilla/dist paths.  I'm also going to add
--with-nspr=path, --with-nss=path, --with-nspr-inc=path, --with-nspr-lib=path, --with-nss-inc=path, and --with-nss-lib=path.  For --with-nspr and --with-nss, the path will be the path containing the lib and include directories.  For the others, they will specify the full path to the lib or include directory.
We're working on Red Hat and Fedora right now to add NSPR, NSS, and LDAP C SDK to the OS, so in the future it should be much easier to build this on those platforms.  I'll be doing the RPM work for the LDAP C SDK as well.

Comment 11

[Rich Megginson]

I've opened another bug for the RPM and other build work I'm doing - bug 322618
Go ahead and close out this bug unless there is some more cleanup that needs to be done that is not related to the other work I'm doing.

Comment 12

[Mark Smith [:mcs]]

I am OK with closing this (a good amount of cleanup was done).  Chris?

Comment 13

[Mark Banner (:standard8)]

Closing based on comments 11 & 12 and the fact that no-one has objected.