72141 - Enable XSLT in default builds

Status: VERIFIED FIXED

(Core :: XSLT, defect)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

ASAP.

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Over to Peter.

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

When you enable it, could you make it possible to disable it if you don't want
it? On windows, if you see DISABLE_XSLT environment variable set do not build
(see how DISABLE_TESTS is done in makefile.win files).

On Unix it should be some configure option, like --disable-xslt.

Comment 3

[Axel Hecht]

we use the --enable-xslt currently to set MOZ_XSL, to switch between building
mozilla module and standalone. Some magic on windows as well.
Bug 54916 talks about having MOZILLA_CLIENT optionally, which would be the
right way to switch, see the comments there. If we could solve that bug, 
building with or without XSLT would be just a matter of building the extensions
dir or not. This could be done easily on windows and unix. nothing can be done
easily on mac. (which is just my usual flame to get peterv going)

Comment 4

[Axel Hecht]

the |Makefile|s are in the way of building in the srcdir on unix, adding 
dependency

Axel

Comment 5

[Axel Hecht]

We are going to need a test run on the tinderboxens, adding leaf.
Leaf, when should we enable XSLT, when is a good time to do some test builds?
For build instructions, see
http://www.mozilla.org/projects/xslt/index.html#build

Axel

Comment 6

[Peter Van der Beken [:peterv]]

Attaching a patch to turn it on in all platforms. I hope we can still get this 
into 0.9. Looking for an r and an sr. Note also bug 74879, which must be fixed at 
the same time.

Comment 7

[Peter Van der Beken [:peterv]]

Attachment: Patch to run on Transformiix in default build

Comment 8

[Axel Hecht]

r=[e-mail]

Comment 9

[Peter Van der Beken [:peterv]]

Anyone want to sr? Leaf? Cls?

Comment 10

[cls]

I think it's kinda late to throw this switch for 0.9.  Also, I already said no
to the toplevel standalone transformix configure option.  Make it use the
toplevel --enable-modules like xpcom,xpconnect, js,etc or have its own build
system (like nspr, nss, xmlterm).  Don't mix them.

Comment 11

[Peter Van der Beken [:peterv]]

Well, I didn't know you objected, so please explain why. The system as it
currently works looks pretty neat to me, but then again, I'm a unix build system
newbie so what do I know. Also, could you please explain what xpcom, xpconnect,
js, ... do differently when they're built standalone? I tried to find where they
special-case their build logic but I haven't found it. As to your suggestion of
following nspr, nss, ... examples, that seems a lot of work, and I doubt it is
worth the effort. There are three people actively contributing on this project:
me (full-time) and two Mozilla volunteers. I don't see how we could pull this off.

Comment 12

[chris hofmann]

trying to shut down 0.9 and get 0.9.1 open  for development.
moving this to 0.9.1

Comment 13

[cls]

As I spend far too much time in the build system, it looks fairly cluttered and
in constant need of cleanup (that never comes).  What does transformiix need to
do in a toplevel configure option that could not be done in the existing
standalone config option?  Nothing.  That's part one of why I object.  

Ideally, none of the modules should do anything differently when they are
compiled standalone.  A standalone build for these modules is just building them
and their prerequisties without building all of mozilla.  Xpconnect needs a
define to trim off certain mozilla specific features although I believe the
long-term plan is to remove the external dependencies or make them runtime
optional (ala xpcom).   What you are proposing is creating an option to build a
special non-mozilla version of transformiix; which I believe should not be part
of the Mozilla build system.  And that's part two of my objection.

IIRC, xmlterm is maintained by a single person and also has a separate build
setup to build standalone.  

Comment 14

[Peter Van der Beken [:peterv]]

I really hate to do this, but I've split up the patch in a part that turns it on
in the default build, and another that provides the standalone option in the
Mozilla build system. As only the second seems to be rejected, I hope to be able
to at least check the first in. As I understand it (but I wasn't there), it was
decided a while ago to reuse the Mozilla build system for the standalone. I
think that was a good decision, but cls seems to disagree now so we're blocked.
Note that when this goes in, you won't be able to build the standalone version
on Linux anymore. cvs.mozilla.org is the primary source for Transformiix, so
this is a very bad thing, and we'll need to solve it quickly.

Comment 15

[Peter Van der Beken [:peterv]]

Attachment: Turn on Transformiix in the default build

Comment 16

[Peter Van der Beken [:peterv]]

Attachment: Provide build option for standalone inside Mozilla build system

Comment 17

[Peter Van der Beken [:peterv]]

So can I get a review and super-review on attachment 33181 [details] [diff] [review] (Turn on Transformiix
in the default build)? Adding some r/sr volunteers ;-).

Comment 18

[Simon Fraser [no longer active]]

sr=sfraser for the Mac parts. Does transormiix have a jar.mn file?

Comment 19

[Peter Van der Beken [:peterv]]

Thanks Simon. No jar.mn, we don't have chrome to install (we used to have a test
chrome, but I don't think we should ship it and it's broken).

Comment 20

[Peter Van der Beken [:peterv]]

Ok, Nisheeth made me realize I forgot to diff two files (for Windows). Attaching
new patch.

Comment 21

[Peter Van der Beken [:peterv]]

Attachment: Updated patch (with all changes for Windows)

Comment 22

[Nisheeth Ranjan]

r=nisheeth for the Linux and Windows part of the patch.

Comment 23

[Johnny Stenback (:jst)]

sr=jst

Comment 24

[Peter Van der Beken [:peterv]]

Attachment: Really turn it on on linux

Comment 25

[cls]

r=cls on attach 34059

Comment 26

[Peter Van der Beken [:peterv]]

Checked in on Windows and Mac. Backed out on unix platforms. Trying to figure
out what the problem is on unix, seems to be a recent change that triggered this.

Comment 27

[Peter Van der Beken [:peterv]]

Attachment: Additional patch

Comment 28

[Peter Van der Beken [:peterv]]

It seems we now need this additional patch in
mozilla/extensions/transformiix/build/Makefile.in.

Comment 29

[cls]

r=cls on attach 34067

Comment 30

[Axel Hecht]

Attachment: proposed fix for worms bustage

Comment 31

[Axel Hecht]

adjusting dependencies. mkaply found some bustage for os/2, thanx for testing.
I filed a new bug. as peterv broke standalone, I removed that dependency.
I also added the NaN bug, which is essential for OS/2, they don't have a 
isnan call in their libs. I'm not sure how to workaround that one.

Axel

Comment 32

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: patch I needed to get transformiix to build on gcc 2.7.2.3

Comment 33

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The above patch is what I needed to build on my copy of gcc 2.7.2.3.  It
contains the NULL->nsnull change that I suggested on IRC this morning plus
additional constructors for StringResult and StringExpr (gcc 2.7.2.3 doesn't
want to create a temporary there (or was it finding the two existing
constructors ambiguous when it did?)... and really the constructors perhaps
ought to be explicit so no compiler would create such a temporary).

Comment 34

[Nisheeth Ranjan]

I just checked in the patches to enable Transformiix on Linux.  For now, OS/2
doesn't build Linux.  Once bug 53518 is fixed, we'll enable Transformiix on OS/2
also.

Comment 35

[Axel Hecht]

bitching buttons, verfication spam