108259 - support statically linked TestGtkEmbed

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: GTK Widget, defect, P3)

Description

[Chris Waterson]

I put together a hack so that TestGtkEmbed can be built statically. I'm doing
this mostly to see what our ``best case'' memory usage is on low-memory devices.
I'm not sure whether or not this is worth checking in, but I thought I'd slap
the patches somewhere so I could move 'em between trees.

Comment 1

[Chris Waterson]

Attachment: kludge

Comment 2

[Christopher Blizzard (:blizzard)]

I would love to see this as something that's actually supported.  You aren't the
only one who wants to see this.  I've gotten multiple requests for it even
though I haven't even the slightest clue how to do it.

Comment 3

[Chris Waterson]

FWIW, the above patch won't work if applied to a clean tree: by the time we want
to link TestGtkEmbed, we haven't built some of the libraries. Who wants to bring
back the ``libs'' phase? ;-)

Comment 4

[Mike Shaver (:shaver emeritus)]

Better: build executables last in the install phase.

I think this would be a lot easier with a non-recursive setup, where each module
can just list the libs it knows how to make and their dependencies, and we can
let make figure out what to build.

Is that still pie-in-the-sky, or do we have a hope?  As we get into more and
more variations of build targets for embedders or platform-bundlers or
constrained platforms (to say nothing of all the dev tools like profilers and
such), that sort of setup would pay off hugely in terms of flexibility.

Comment 5

[hacker formerly known as [e-mail]]

So what Shaver is really saying is "RMCH! RMCH!". :-)  But I don't see how that
would help here.  The problem is that developers aren't exactly keeping track of
what they depend upon..."It's in dist/?  Then it's fairgame!".  RMCH isn't going
to solve that.  RMCH also has the drawback of assuming that all of the files are
compiled with the same CFLAGS which breaks down for us as many of our modules
compile with special -D_NS_IMPL_FOO flags. 

For now, we should just move TestGtkEmbed further down in the build.

Comment 6

[Mike Shaver (:shaver emeritus)]

The RMCH paper doesn't show separate CFLAGS, but it's been done and it works fine.
RMCH doesn't solve the bogodependency problem (what could?), but it does solve
the build-order problem as long as we have an acyclic build graph.  And it
provides a lot more flexibility in terms of building subsets of the tree.  Given
that _everyone_ builds a subset of the tree, it seems like something we should
consider.

Comment 7

[hacker formerly known as [e-mail]]

I have no doubt that RMCH could work on a module level as I implemented part of
it for bug 11219 once.  But I'm having trouble seeing it working for the tree as
a whole and I think it's overkill for this particular problem.  WRT the CFLAGS
issue, can you point me to an example that uses different CFLAGS for various
sourcefiles to build a project from a single make invocation?

Comment 8

[Chris Waterson]

Attachment: More butchery!

This patch fixes the build order, so that embedding/browser/gtk/tests is built
last. It also includes some hackery to cull out components _not_ included in
the embedding manifest.

I'm not really sure I want to check this in, but it sure is useful for trying
to figure out the ``best case'' footprint scenario for a GTK embedding.

Comment 9

[Chris Waterson]

Attachment: Cleaned up.

Turns out that I'd edited a Makefile instead of a Makefile.in. Also added a
conditional so that you could build stuff with all the default componentry if
you wanted to. (Why am I doing this? Do I secretly want to check it in? I'll
have to go lay on my couch for a while to ponder this.)o

Comment 10

[hacker formerly known as [e-mail]]

Comment on attachment 60396 [details] [diff] [review]
Cleaned up.

Geez, I have to go lay down too after just looking at that.  r=cls

Comment 11

[hacker formerly known as [e-mail]]

One thing. That toplevel Makefile.in change needs to wrap the +=
embedding/browser/gtk/tests inside a MOZ_ENABLE_GTK ifdef.

Comment 12

[hacker formerly known as [e-mail]]

*** Bug 92485 has been marked as a duplicate of this bug. ***

Comment 13

[Chris Waterson]

Heh, I was just about to chuck this patch. Should I check it in for
mozilla-0.9.9? blizzard, could you sr=?

Comment 14

[Christopher Blizzard (:blizzard)]

My Makefile-fu is not strong but the code bits look fine to me. sr=blizzard on
that.  It also looks harmless so you can check it in for 0.9.8 if you want.

Comment 15

[Chris Waterson]

Fix checked in.

Comment 16

[Colin Blake]

There's some fallout due to these changes. See bug 126163 and bug 126165.