There are some one-off targets in xpcom/typelib and xpcom/idl-parser that are currently processed as part of the export tier traversal. They are needed for non-recursive XPIDL processing. I plan to move them into the new precompile tier in this bug.

There's a lot packed into this patch. Careful review is needed. This patch is about moving some one-off export targets that are required for XPIDL/xpt processing into the new precompile tier. You should start with config/makefiles/precompile. Notice how we now pull in pieces from xpcom/typelib and xpcom/idl-parser. xpcom/idl-parser's Makefile wasn't doing anything that required rules.mk or moz.build files. So, I moved content into a standalone "precompile.mk." It is essentially a Makefile.in with a different name and without rules.mk. xpcom/moz.build was educated to create this file at config.status time. I also moved the one-off check target into xpcom/Makefile.in. xpcom/typelib was another special tree. I consolidated some Makefile.in/moz.build rules to eliminate excessive traversal. However, the big change was breaking the link between xpcom's traversal. xpcom/typelib now stands on its own. It is now referenced from the precompile tier moz.build file. This is somewhat hacky, I concede. However, I can't think of anything better that doesn't involve tons of work. I confess that I still don't fully grok how all this xpt/typelib stuff works. I mean, I do grok how it's all hooked together in the build system. However, I'm lacking the historical context. Why is it written in C (and not say C++)? Why isn't it in the base tier? I'm sure there are no shortage of ways we can make all of this suck less. However, I think the current patch is a good compromise that allows us to move forward with non-recursive XPIDL processing with minimal effort. I will entertain alternative ideas, of course. https://tbpl.mozilla.org/?tree=Try&rev=dfd5060ccf0a

> xpcom/idl-parser's Makefile wasn't doing anything that required rules.mk > or moz.build files. So, I moved content into a standalone > "precompile.mk." It is essentially a Makefile.in with a different name > and without rules.mk. xpcom/moz.build was educated to create this file > at config.status time. I also moved the one-off check target into > xpcom/Makefile.in. afaik this + moving the SDK_BINARY stuff in xpcom/typelib/xpcom/Makefile.in which just coppies some python should be enough. > xpcom/typelib was another special tree. I consolidated some > Makefile.in/moz.build rules to eliminate excessive traversal. However, > the big change was breaking the link between xpcom's traversal. > xpcom/typelib now stands on its own. It is now referenced from the > precompile tier moz.build file. This is somewhat hacky, I concede. > However, I can't think of anything better that doesn't involve tons of > work. I'm not sure why you need to do this, everything other than coppyingthe python and generating the parse tables should be just fine to do in libs (even though that isn't where we do it today) > I confess that I still don't fully grok how all this xpt/typelib stuff > works. I mean, I do grok how it's all hooked together in the build > system. However, I'm lacking the historical context. Why is it written > in C (and not say C++)? Why isn't it in the base tier? I'm pretty sure the only reason its built before libs is historical. Before the compiled xpidl parser went away a couple years ago we need to build it to parse xpidl, which of course meant you needed to compile it before you start exporting stuff. > I'm sure there are no shortage of ways we can make all of this suck > less. However, I think the current patch is a good compromise that > allows us to move forward with non-recursive XPIDL processing with > minimal effort. I will entertain alternative ideas, of course. I'm pretty sure you could just do the first part of this and leave the second part to a later cleanup bug.

Comment on attachment 785104 [details] [diff] [review] bug 900330 - part 0 clean up xpcom/typelib/xpt/src/Makefile.in we don't need to build the C xpt code before idl parsing anymore so change to compile it during libs Review of attachment 785104 [details] [diff] [review]: ----------------------------------------------------------------- Nice cleanup! ::: xpcom/typelib/xpt/src/Makefile.in @@ +15,1 @@ > USE_STATIC_LIBS = 1 I bet we don't need this anymore either, since we're only linking this into libxul.

Comment on attachment 785329 [details] [diff] [review] bug 900330 - generate the xpidl parser during precompile instead of export Review of attachment 785329 [details] [diff] [review]: ----------------------------------------------------------------- ::: config/makefiles/precompile/Makefile.in @@ +33,5 @@ > webidl: > $(call make_subtier_dir,WebIDL,$(DEPTH)/dom/bindings,webidl) > + > +xpidl-parser: > + $(call make_subtier_dir,XPIDLParser,$(DEPTH)/xpcom/idl-parser,xpidl-parser) This Makefile is starting to feel repetitive. I wonder if gps has thought about how we're going to represent this stuff in moz.build.

remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/9caf24f498d5 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/e5ebdc689486 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/60287a04a9ea

https://hg.mozilla.org/mozilla-central/rev/9caf24f498d5 https://hg.mozilla.org/mozilla-central/rev/e5ebdc689486 https://hg.mozilla.org/mozilla-central/rev/60287a04a9ea