Closed Bug 145343 Opened 18 years ago Closed 18 years ago

{libjar,zlib}/standalone needs BUILD_MOZ_INSTALLER, new module name

Categories

(SeaMonkey :: Build Config, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mcafee, Assigned: mcafee)

References

Details

Attachments

(1 file, 1 obsolete file)

libjar requires zlib.
libjar adds libjar/standalone for Linux:

  [mozilla/modules/libjar/Makefile.in]
  # Linux and Solaris installer needs standalone libjar
  ifneq (,$(filter Linux SunOS WINNT,$(OS_ARCH)))
  DIRS        = standalone
  endif

However, the corresponding standalone zlib lib ifdef happens
in the top-level Makefile and I miss this when trying to build
the zlib module:

  [mozilla/Makefile.in]
  # Installer needs standalone libjar, hence standalone zlib
  ifneq (,$(filter Linux SunOS WINNT,$(OS_ARCH)))
  tier_1_dirs    += modules/zlib/standalone
  endif

[last mail summary per stated problem, above]

Alec Flett wrote:

> I guess I don't understand why its at the top level...seawood, I think you're
> the only one who can answer that. I guess I feel like standalone zlib is
> small enough that we should just included it with zlib itself...

Personal preference mainly.  I wanted to avoid a wasted 'make' invocation on
most platforms caused by always entering modules/zlib to do nothing.  Remember
that until recently, modules/zlib wasn't even traversed because we used the
system version of zlib by default.  If you  want to move the standalone* ifdef
from the toplevel Makefile, then you'll have to move the MOZ_SYSTEM_ZLIB ifdef
as well.

* standalone is such a misnomer there.  That version is just always built static
for the installer and the normal zlib build has no non-system deps.

> if that isn't an option, I think we should declare standalone libjar to be a >
seperate module (libjar-standalone?) and add a new entry for
> modules/libjar/standalone in module2dir.pl

That sounds like a good idea as we don't need either of these for embedding.

Chris McAfee wrote:

> Two questions here, should/can we move the zlib ifdef
> into mozilla/modules/zlib/Makefile.in ?  Also, should we have
> a named ifdef here instead of makefile filter stuff?

Can, yes.  Should, maybe.  I'm fine with a named ifdef. BUILD_MOZ_INSTALLER, maybe?
cc's
Blocks: 143524
-> mcafee
Assignee: Matti → mcafee
This should actually be under Build Config
Assignee: mcafee → seawood
Component: Browser-General → Build Config
QA Contact: imajes-qa → granrose
Back to mcafee.
Assignee: seawood → mcafee
disable static zlib, libjar with --disable-installer-libs.
Still looking at this; I think I named this right, but
maybe seawood could comment.  This patch gets me past my original problem,
we can pursue new module name if needed.

I looked for changes on Win32/Mac and came up empty, was this only
ifdef'd for gmake builds?
Comment on attachment 85377 [details] [diff] [review]
Switch to named ifdef, moved platforms from the old ifdef into configure.in.  Linux, Solaris, Win32 still build installer libs unless it gets explicitly turned off.

Just disabling the building of the standalone libs is going to cause problems
for us when someone tries to build the moz tree with that option...believe me
someone will.	The option should be just --disable-installer and should skip
building the installer as well as the standalone libs.
Attachment #85377 - Flags: needs-work+
Comment on attachment 85485 [details] [diff] [review]
Use --disable-installer & MOZ_INSTALLER

r=mcafee, thanks to seawood for better makefile syntax in a few places, and I
forgot the autoconf.mk.in change.
Attachment #85485 - Flags: review+
The patch has been checked in.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Oops. I forgot about the module renanming.  How about jar_standalone &
zlib_standalone?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
those names sound ok to me.
ditto
So putting the standalone copies of jar & zlib into their own modules is proving
troublesome.  The standalone copies will still have a dependency upon the
non-standalone module because we copy/symlink the source from the non-standalone
dir to standalone dir.  The copy is done as an explicit rule at the end of the
export pass which is too late to copy the xpidlsrcs so that they can be
regenerated and installed into $(DIST)/include/jar_standalone.  So if we stay
with letting the installer use the jar dependency instead of jar_standlone, then
there's really no reason to rename the modules as the MOZ_INSTALLER ifdef should
keep us from building those dirs in an embedding build and they have no mor
dependencies than the original dirs. 
I think just the ifdef stuff we have now is adequate.
Should we mark this fixed then?
Marking fixed.
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.