176306 - Mozilla fails to build properly with Perl < 5.6

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P1)

Description

[Philip K. Warren]

In config/rules.mk, '--' is used as a delimiter between configuration options
passed to config/make-jars.pl. This support was not added until Getopt::Std
v1.02, which was included in Perl v5.6 and above. This causes the $defines not
to be set in config/make-jars.pl, which in turn causes the preprocessor not to
work correctly (XP_UNIX and other defines are never set).

Comment 1

[Asa Dotzler [:asa]]

bug 175692?

Comment 2

[Philip K. Warren]

This is not the same as Bug 175692. Phoenix builds properly, however the 
following error message is printed in the build log when running make-jars.pl:

Unknown option: -

The entire product is built, but the correct defines are not passed to the 
preprocessor.

Comment 3

[Roland Mainz]

For the log:
One symptom of this bug is that the "Print Job Options dialog" is missing from
FireFox (on Unix/Linux) when Perl is < 5.6 (the files are in the JAR - but they
are empty).

Comment 4

[cls]

This has, unfortunately, become a general mozilla build problem since the
preprocessor is being used by default for all chrome files.  The preprocessor
should be fixed now or the build requirements bumped up to perl 5.6. 

Comment 5

[cls]

Attachment: Require perl 5.6.0 or higher

Apparently, there's no way to get the Getopt::Std module outside of the core
perl distribution so we're going to have to bump the required perl version.

Comment 6

[Daniel (Leaf) Nunes]

Comment on attachment 145193 [details] [diff] [review]
Require perl 5.6.0 or higher

take that, old software!

Comment 7

[chris hofmann]

Comment on attachment 145193 [details] [diff] [review]
Require perl 5.6.0 or higher

a=chofmann for 1.7

Comment 8

[cls]

In case anyone's wondering, we're waiting for btek to get updated before
checking in the change on the trunk.  It could probably land on the 1.7 branch
without a problem.

Comment 9

[cls]

Bah. Someone decided to put up a RH6.2 tinderbox on the branch as well. 

Comment 10

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

How hard would it be to make the preprocessor work with older versions of perl?

Updating btek is not a trivial job -- probably on the order of a day's work,
since it also acts as the pageload server and various perl modules need to be
set up, and mod_perl needs to be reconfigured, etc.  And even once that's done,
btek would no longer be the standard yardstick against which we've been
measuring for the past few years.

Comment 11

[cls]

I have no idea how hard it would be to tweak the preprocessor.  I'm trying to
enforce the defacto standard that was set apparently awhile ago and avoid the
fiasco we went/are going through with the File::Spec v0.8 dependency (which
still isn't resolved).

Updating the version of perl used by the btek & sparky tinderbox builds does not
require updating the system version of perl.  Install perl 5.6.1 or whatever in
a custom directory and set PERL appropriately in the mozconfig files. 

Comment 12

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

I'm trying to say that before telling reasonably large numbers of people to
spend an hour updating their perl, it's probably worth spending a little more
time trying to fix the preprocessor.

Comment 13

[cls]

Well, when you find a solution that doesn't break the all of the perl variants
that we currently support, then let us know.  Until then, we shouldn't allow
people to build using tools that are known not to give the proper results.

Comment 14

[Benjamin Smedberg]

Umm, this is a bug with make-jars.pl, not the preprocessor itself, right? I can
think of at least one hacky solution (since we only pass -Ddefine options to the
preprocessor from make-jars.pl, instead of using the -- delimiter, just pass all
-Doptions to the preprocessor directly).

Comment 15

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

(In reply to comment #13)
> that we currently support, then let us know.  Until then, we shouldn't allow
> people to build using tools that are known not to give the proper results.

...and the normal way to do that, when the case for bumping the build
requirements hasn't been made, is to back out the patch that caused that
increase in the build requirements.

Comment 16

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

(Could all the -D options for the preprocessor be passed in a single long quoted
string?)

Comment 17

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

Never mind that -- there are quoting problems.  But we could presumably search
for "--" and set $defines before calling getopt -- it wouldn't get rid of the
warnings, though.

Comment 18

[cls]

> ...and the normal way to do that, when the case for bumping the build
> requirements hasn't been made, is to back out the patch that caused that
> increase in the build requirements.

True. Unfortunately, this isn't a normal case since the bug sat ignored for the
better part of 1.5 years, drivers made a working firefox build a requirement in
the meantime and we started to use the xul preprocessor for the default build.  

Given the problems with the File::Spec workaround (bug 232002) & this bug's
issues with the getopt delimiter, I'd say that the case for bumping the build
requirements has already been made.

Comment 19

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

Attachment: patch to make-jars.pl

Comment 20

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

Also, I think your version test isn't the right one for this bug, since btek and
sparky both look like they pass the correct arguments to the preprocessor, but
they fail the version test.

Could somebody who *does* see the problem test this patch?

Comment 21

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

Never mind comment 20.  I was thinking I could tell from the build log, but
that's a different caller.

Comment 22

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

So, yeah, I tested this on sparky, and it does as I expected.  Before, the
incorrect arguments were passed to the preprocessor, and now the correct ones
are being passed to the preprocessor.

Comment 23

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

Fix checked in to trunk, 2004-04-22 13:52 -0700.

Comment 24

[Asko Tontti]

David, you are assigning a list to a scalar variable:

  my $defines = @ARGV[ $ddindex .. $#ARGV ];

You probably ment:

  my $defines = join(" ", @ARGV[ $ddindex .. $#ARGV ]);

Comment 25

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

(In reply to comment #24)
> David, you are assigning a list to a scalar variable:
> 
>   my $defines = @ARGV[ $ddindex .. $#ARGV ];
> 
> You probably ment:
> 
>   my $defines = join(" ", @ARGV[ $ddindex .. $#ARGV ]);

Change made (although with single quotes instead of double).  It seems to have
the same effect, though.  Not that I know why...

Comment 26

[Asko Tontti]

It shouldn't have the same effect. Compare the output of these commands

 a) perl -le 'my $t = ("a", "b", "c"); print $t'
    output: c

 b) perl -le 'my $t = join(" ", "a", "b", "c"); print $t'
    output: a b c

Comment 27

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

I put a print in the script itself and it did have the same effect.  I don't
know what the difference is.

Comment 28

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

(By difference, I mean the difference between the script and the examples in
comment 26.)

Comment 29

[Asa Dotzler [:asa]]

Comment on attachment 146141 [details] [diff] [review]
patch to make-jars.pl

a=asa (on behalf of drivers) for checkin to 1.7

Comment 30

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

Fix checked in to MOZILLA_1_7_BRANCH, 2004-04-26 16:13 -0700.