170737 - (xulpp) Revive XUL preprocessor

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Blake Ross]

It'd be nice if we could get the xulpp working again.  There are still two 
platform overlays in browser.xul.

Comment 1

[Blake Ross]

blue sky target.

Comment 2

[Blake Ross]

blue sky target.

Comment 3

[(not reading, please use [e-mail] instead)]

snooping, as this would help other projects as well.

Comment 4

[Brian Ryner (not reading)]

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

Comment 5

[Brian Ryner (not reading)]

Attachment: patch

This hooks up hixie's preprocessor (see
http://software.hixie.ch/utilities/unix/preprocessor/ )

You can mark a file as needing preprocessed in jar.mn by putting a * as the
first character on a line.  If you need to specify "+" for overrides, put it
after the *.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

shouldn't this be Mozilla: Build Config rather than Phoenix: General

Comment 7

[Brian Ryner (not reading)]

Attachment: minor tweak

die() if the preprocessor command fails

Comment 8

[hacker formerly known as [e-mail]]

Comment on attachment 101930 [details] [diff] [review]
minor tweak

Just noting what I stated on IRC.  Since this new jar.mn syntax & functionality
isn't meant for general use (ie, there's no support for the mac classic build's
Jar.pm module), there should be some obvious indicator that this is meant only
for the phoenix builds and shouldn't be enabled for the mozilla builds by
default.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

>this is meant only
>for the phoenix builds and shouldn't be enabled for the mozilla builds by
>default.

why shouldn't mozilla benefit from the changes? wouldn't it be a better idea to
fix this to work on the mac, and use it in mozilla as well?

Comment 10

[Brian Ryner (not reading)]

Attachment: patch #3

ifdef the rules MOZ_PHOENIX; fix a bug in checking the return result of the
system() call in make-jars.pl.

Comment 11

[Hixie (not reading bugmail)]

biesi: fix it for mac classic and it can of course be turned on for the trunk.
As it is, none of the developers have the time to do so.

Comment 12

[Brian Ryner (not reading)]

Comment on attachment 102183 [details] [diff] [review]
patch #3

attached the wrong patch

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

I lack a Mac, alas :/

Comment 14

[Brian Ryner (not reading)]

Attachment: the real patch #3

This is what I meant to post earlier.

Comment 15

[(not reading, please use [e-mail] instead)]

jj, leaf and cls, according to hixie / bryner, the only thing stopping us from
having this on the trunk is mac classic.

I think we could make really good use of this on the trunk.

how hard would it be to make it work for mac classic?

Comment 16

[hacker formerly known as [e-mail]]

Based upon my previous experience with the mac classic build system, it would
involve rewritting preprocessor.pl so that it could be loaded as a perl module
(.pm) instead of invoking a separate perl process.  Simon may be able to point
out any other problem spots.

Comment 17

[hacker formerly known as [e-mail]]

Comment on attachment 102317 [details] [diff] [review]
the real patch #3

r=cls

Comment 18

[Simon Fraser [no longer active]]

The Mac classsic build doesn't run make-jars.pl; it has its own jar packaging
stuff. So making this work for Mac classic is non-trivial, and of questionable
utility, since we're looking towards Macho (i.e. unix-based) builds now.

If we don't add xulpp support to mac classic, will this break the builds? Or is
this an optional 'optimization' thing?

Comment 19

[Asa Dotzler [:asa]]

a=asa for checkin to 1.2b

Comment 20

[Hixie (not reading bugmail)]

Simon: It's not just an optimisation -- a file that requires the preprocessor
won't be usable without being preprocessed.

Comment 21

[(not reading, please use [e-mail] instead)]

> If we don't add xulpp support to mac classic, will this break the builds? Or 
> is this an optional 'optimization' thing?

right now, it's phoenix only.

my understanding is if we wanted to use the preprocessor on the trunk, we'd 
have to have it working on all platforms that we plan on building on.

xul with:

#ifdef DEBUG
  <button label="debug" oncommand="dump(getState() + '\n')" />
#endif

would not get pre-processed out, and would fail on startup.

Comment 22

[Brian Ryner (not reading)]

checked in.

Comment 23

[Jan Varga [:janv]]

>#ifdef DEBUG
>  <button label="debug" oncommand="dump(getState() + '\n')" />
>#endif

that would be really cool to have

Comment 24

[Hixie (not reading bugmail)]

well it wouldn't fail on startup (it's still valid XUL) but it would definitely
cause a smoketest blocker...

Comment 25

[selmer (gone)]

Bug 135533 was inappropriately closed against this bug since 135533 requests a
fix on the trunk and this closed bug has not yet resulted in a fix on the trunk.
 If this bug is not going to be re-opened for a trunk fix, then I'm going to
reopen 135533.  Please let me know which bug you prefer.  Steve

Comment 26

[Simon Paquet [:sipaq]]

v.