Last Comment Bug 701371 - Move memory/mozutils somewhere else
: Move memory/mozutils somewhere else
Status: RESOLVED FIXED
[requires clobber][qa-]
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla12
Assigned To: Mike Hommey [:glandium]
:
:
Mentors:
Depends on: 721801
Blocks: 696422 709776 716395 716397
  Show dependency treegraph
 
Reported: 2011-11-10 07:47 PST by Mike Hommey [:glandium]
Modified: 2012-02-16 09:12 PST (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed


Attachments
Rename toplevel memory directory to mozutils (7.66 KB, patch)
2011-11-10 07:48 PST, Mike Hommey [:glandium]
no flags Details | Diff | Splinter Review
Move mozutils to top-level (12.03 KB, patch)
2011-12-12 07:18 PST, Mike Hommey [:glandium]
no flags Details | Diff | Splinter Review
Rename mozutils to mozglue, and move it to top-level (50.81 KB, patch)
2011-12-22 00:49 PST, Mike Hommey [:glandium]
no flags Details | Diff | Splinter Review
Rename mozutils to mozglue, and move it to top-level (53.91 KB, patch)
2011-12-22 01:02 PST, Mike Hommey [:glandium]
khuey: review+
Details | Diff | Splinter Review
Rename mozutils to mozglue. c-c part. rs=Callek (10.83 KB, patch)
2011-12-27 10:18 PST, Mike Hommey [:glandium]
no flags Details | Diff | Splinter Review
Rename mozutils to mozglue, and move it to top-level - version for aurora (54.00 KB, patch)
2012-01-25 08:49 PST, Mike Hommey [:glandium]
mh+mozilla: review+
blassey.bugs: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Mike Hommey [:glandium] 2011-11-10 07:47:13 PST
Since bug 677501, we have a mozutils library which consists of:
- jemalloc
- a custom ELF linker on Android
- a modified CRT on Windows

The rationale for creating that mozutils library is that it was needed for future works, such as bug 662814, requiring to be available from libxul as well as the main binary, components, and possibly third-party libraries.

I abused the memory top-level directory and placed the mozutils directory under it. I think it would be better to make things clearer, and more long-term-oriented, by renaming the memory toplevel directory to mozutils. That way, bug 662814 and subsequent similarly centralized utils will have a place where to live.

The only downside is that mozalloc, which is also under memory is not part of mozutils. But I believe this could (and probably should) be changed.
Comment 1 Mike Hommey [:glandium] 2011-11-10 07:48:37 PST
Created attachment 573507 [details] [diff] [review]
Rename toplevel memory directory to mozutils
Comment 2 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-11-10 07:49:26 PST
Both mozalloc and jemalloc live in this directory ... it seems like it would make more sense to move mozutils out of memory/ and leave everything else.
Comment 3 Mike Hommey [:glandium] 2011-11-10 07:51:27 PST
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #2)
> Both mozalloc and jemalloc live in this directory ... it seems like it would
> make more sense to move mozutils out of memory/ and leave everything else.

Point is, mozalloc could/should be merged into mozutils. jemalloc IS in mozutils already.
Comment 4 Benjamin Smedberg [:bsmedberg] 2011-11-10 08:22:01 PST
I don't think we should do this. The directory structure doesn't need to reflect the current library structures (which can change), but should provide a human-readable structure for understanding our code.
Comment 5 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-11-10 08:36:45 PST
(In reply to Mike Hommey [:glandium] from comment #3)
> Point is, mozalloc could/should be merged into mozutils. jemalloc IS in
> mozutils already.

content/, layout/ and plenty of other stuff are in libxul, but I don't think anyone wants to move them into toolkit/library

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> I don't think we should do this. The directory structure doesn't need to
> reflect the current library structures (which can change), but should
> provide a human-readable structure for understanding our code.

+1
Comment 6 Mike Hommey [:glandium] 2011-11-10 08:46:38 PST
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #5)
> (In reply to Mike Hommey [:glandium] from comment #3)
> > Point is, mozalloc could/should be merged into mozutils. jemalloc IS in
> > mozutils already.
> 
> content/, layout/ and plenty of other stuff are in libxul, but I don't think
> anyone wants to move them into toolkit/library

But their content are about content, layout, etc.
We could have a separate home for mozutils, since it's not "memory" stuff, but where ? a new top-level directory ? then why keep "memory", considering the amount of stuff in it and considering it ends up in mozutils anyways?
Comment 7 Mike Hommey [:glandium] 2011-12-08 05:57:14 PST
I am going to move tri-license things from other-licenses/android under mozutils, and will add the new ELF linker there too. In both cases, memory/ is the wrong top-level directory.

Putting the memory/ toplevel directory issue aside, may i move mozutils so that it becomes a new toplevel directory, or do you have better locations?
Comment 8 Mike Hommey [:glandium] 2011-12-12 07:18:30 PST
Created attachment 580901 [details] [diff] [review]
Move mozutils to top-level
Comment 9 Brendan Eich [:brendan] 2011-12-15 14:45:54 PST
Suggest new top level name should be libc-overrides or mozlibc -- not libc and not mozutils. The library name stem can follow to match, if that's doable. May help decide between explicit/long -overrides and moz- prefix names.

/be
Comment 10 Mike Hommey [:glandium] 2011-12-15 23:07:36 PST
(In reply to Brendan Eich [:brendan] from comment #9)
> Suggest new top level name should be libc-overrides or mozlibc -- not libc
> and not mozutils. The library name stem can follow to match, if that's
> doable. May help decide between explicit/long -overrides and moz- prefix
> names.

How about cglue or c-glue?
Comment 11 Brendan Eich [:brendan] 2011-12-21 15:47:35 PST
After more IRC discussion with Mike, we ended up on mozglue. It's not as likely a honey trap as mozutil(s) but glue is too generic. The libc idea didn't pan out, since we have JNI and perhaps XPCOM glue in here too. It's gluey, don't touch!

/be
Comment 12 Mike Hommey [:glandium] 2011-12-21 15:52:21 PST
(In reply to Brendan Eich [:brendan] from comment #11)
> and perhaps XPCOM glue in here too.

In case bsmedberg reads this, the idea would be to eventually have an initialization glue to replace the xpcom standalone glue he wanted to get rid of before we started requiring it for firefox.
Comment 13 Mike Hommey [:glandium] 2011-12-22 00:49:32 PST
Created attachment 583735 [details] [diff] [review]
Rename mozutils to mozglue, and move it to top-level
Comment 14 Mike Hommey [:glandium] 2011-12-22 01:02:58 PST
Created attachment 583737 [details] [diff] [review]
Rename mozutils to mozglue, and move it to top-level

Added the missing removed-files parts. Also applied bug 707121 to mobile.
Comment 15 Mike Hommey [:glandium] 2011-12-27 10:18:49 PST
Created attachment 584452 [details] [diff] [review]
Rename mozutils to mozglue. c-c part. rs=Callek

rs-ed on irc.
Comment 17 Mike Hommey [:glandium] 2011-12-27 23:44:14 PST
Fixup for windows burnage:
https://hg.mozilla.org/integration/mozilla-inbound/rev/45820730dfa7
Comment 18 Mike Hommey [:glandium] 2011-12-28 03:19:28 PST
Backed out because of random and unexplainable android bustages.
https://hg.mozilla.org/integration/mozilla-inbound/rev/db6e5b2bf92d
Comment 19 Mike Hommey [:glandium] 2012-01-10 00:18:14 PST
Relanded as-is (except for a few context changes). The problem was with bug 709776.
https://hg.mozilla.org/integration/mozilla-inbound/rev/cf890c9c3e4c
Comment 20 Ed Morley [:emorley] 2012-01-10 11:50:30 PST
https://hg.mozilla.org/mozilla-central/rev/cf890c9c3e4c
Comment 21 Justin Wood (:Callek) 2012-01-10 12:46:48 PST
http://hg.mozilla.org/comm-central/rev/fa7ba14da207
Comment 22 Ryan VanderMeulen [:RyanVM] 2012-01-10 18:54:45 PST
This broke js shell packaging (still looking for a now-missing mozutils.dll) and also prevents mozutils.dll from being copied to dist/firefox during packaging. Somehow, mozutils.dll does end up in the firefox zip package, though.
Comment 23 Ryan VanderMeulen [:RyanVM] 2012-01-10 18:56:05 PST
Unless this is just an issue of my objdir needing a clobber?
Comment 24 Ed Morley [:emorley] 2012-01-10 19:10:08 PST
All platforms apart from Linux needed a clobber when I merged, if that helps :-)
Comment 25 Mike Hommey [:glandium] 2012-01-25 08:49:01 PST
Created attachment 591483 [details] [diff] [review]
Rename mozutils to mozglue, and move it to top-level - version for aurora

[Approval Request Comment]
This is a dependency for bug 683127. It only moves code around and changes a library name. No disruption is expected from the former, but for aurora, we may want to skip the latter. Please tell me if we should do so and I will update the patch accordingly.
Comment 26 Mike Hommey [:glandium] 2012-01-26 23:53:17 PST
https://hg.mozilla.org/releases/mozilla-aurora/rev/185d4aa163bc
Comment 27 Philip Chee 2012-01-27 12:05:20 PST
Did someone forget comm-aurora again?
Comment 28 Philip Chee 2012-01-27 12:15:38 PST
Comment on attachment 584452 [details] [diff] [review]
Rename mozutils to mozglue. c-c part. rs=Callek

I have rs from Callek over IRC to push to comm-aurora.

Pushed:
http://hg.mozilla.org/releases/comm-aurora/rev/b808530327a5

Note You need to log in before you can comment on or make changes to this bug.