701371 - Move memory/mozutils somewhere else

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mike Hommey [:glandium]]

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]]

Attachment: Rename toplevel memory directory to mozutils

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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]

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 (Exited; not receiving bugmail, old account, do not use)]

(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]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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]]

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]]

Attachment: Move mozutils to top-level

Comment 9

[Brendan Eich [:brendan]]

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]]

(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]]

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]]

(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]]

Attachment: Rename mozutils to mozglue, and move it to top-level

Comment 14

[Mike Hommey [:glandium]]

Attachment: 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]]

Attachment: Rename mozutils to mozglue. c-c part. rs=Callek

rs-ed on irc.

Comment 16

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/860035a3c04a

Comment 17

[Mike Hommey [:glandium]]

Fixup for windows burnage:
https://hg.mozilla.org/integration/mozilla-inbound/rev/45820730dfa7

Comment 18

[Mike Hommey [:glandium]]

Backed out because of random and unexplainable android bustages.
https://hg.mozilla.org/integration/mozilla-inbound/rev/db6e5b2bf92d

Comment 19

[Mike Hommey [:glandium]]

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]]

https://hg.mozilla.org/mozilla-central/rev/cf890c9c3e4c

Comment 21

[Justin Wood (:Callek)]

http://hg.mozilla.org/comm-central/rev/fa7ba14da207

Comment 22

[Ryan VanderMeulen [:RyanVM]]

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]]

Unless this is just an issue of my objdir needing a clobber?

Comment 24

[Ed Morley [:emorley]]

All platforms apart from Linux needed a clobber when I merged, if that helps :-)

Comment 25

[Mike Hommey [:glandium]]

Attachment: 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]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/185d4aa163bc

Comment 27

[Philip Chee]

Did someone forget comm-aurora again?

Comment 28

[Philip Chee]

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