consolidate nsinstall commands

NEW
Unassigned

Status

()

Core
Build Config
6 years ago
6 years ago

People

(Reporter: joey, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
multiple copies of nsinstall.c exist in the sandbox.  Would it make sense to refactor sources to have consistent behavior and build the tool into a common directory for general use ?

./config/nsinstall.c
./nsprpub/config/nsinstall.c
./security/coreconf/nsinstall/nsinstall.c
./js/src/config/nsinstall.c
It's...complicated. NSPR and NSS are standalone upstream projects. js/src functions more-or-less as a standalone project these days.
(Reporter)

Comment 2

6 years ago
(In reply to comment #1)
> It's...complicated. NSPR and NSS are standalone upstream projects. js/src
> functions more-or-less as a standalone project these days.

For the upstream projects would the problem be coordination or long term maintenance ?  A quick and dirty answer { if upstream owners do not care } might be to patch their makefile so it can either copy the common nsinstall.c in locally for a build or change the makefile nsinstall path so a pre-built binary from bin/obj could be used [ yes this answer is simpler but would introduce a dependency ].

Ummm, ignoring js/ for the moment as there are a few tools in that basket :)

Comment 3

6 years ago
Coordinating with NSS isn't worth the effort. We can coordinate with NSPR, but since they are all separate build systems it probably isn't worth the effort.
Note that we could "simply" override the NSINSTALL variable when going in NSPR, NSS and js, to force them to use whatever the main tree uses.

Comment 5

6 years ago
What problem does that solve?
That would allow to have a canonical implementation of nsinstall, whatever the other projects want to use. Especially, that'd allow to use nsinstall.py in NSPR and NSS (since aiui, nsinstall.py is mostly ready to be used)
You need to log in before you can comment on or make changes to this bug.