Move IDL parsing targets into precompile tier

RESOLVED FIXED in mozilla26

Status

defect
RESOLVED FIXED
6 years ago
Last year

People

(Reporter: gps, Assigned: gps)

Tracking

unspecified
mozilla26
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

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
Attachment #784490 - Flags: review?(ted)
Assignee: nobody → gps
> 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.
Attachment #785104 - Flags: review?(ted) → review+
Attachment #785328 - Flags: review?(ted) → review+
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.
Attachment #785329 - Flags: review?(ted) → review+
Attachment #784490 - Flags: review?(ted)
Depends on: 904891
Depends on: 921816
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.