1247282 - Libical build error when invoking mkderivedvalues.pl perl script [mozmake.exe[5]: *** [icalderivedvalue.h] Error 2]

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[Stefan Sitter [:ssitter]]

Could be regression from Bug 1246894. From https://treeherder.mozilla.org/logviewer.html#?job_id=32313&repo=comm-central

mozmake.exe[5]: Entering directory 'c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/objdir-tb/calendar/libical/src/libical'

C:/mozilla-build/msys/bin/perl.exe -Ic:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/calendar/libical/src/libical/../../scripts  c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/calendar/libical/src/libical/../../scripts/mkderivedvalues.pl \

    -i c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/calendar/libical/src/libical/icalderivedvalue.h.in -h c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/calendar/libical/src/libical/../../design-data/value-types.csv > icalderivedvalue.h

Can't locate readvaluesfile.pl in @INC (@INC contains: . c /builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/calendar/libical/src/libical/../../scripts /usr/lib/perl5/5.6.1/msys /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/msys /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl) at c:/builds/moz2_slave/tb-c-cen-w32-00000000000000000/build/calendar/libical/src/libical/../../scripts/mkderivedvalues.pl line 5.

Makefile:196: recipe for target 'icalderivedvalue.h' failed

Comment 1

[aleth [:aleth]]

Can you move that perl wrapper script to libical/scripts and then call it from the Makefile, if you can't do without it altogether?

Comment 2

[Stefan Sitter [:ssitter]]

Maybe. Someone familiar with perl or makefile or both should take a look.

Comment 3

[Jorg K (CEST = GMT+2)]

Mike, could you lend a hand here? Windows builds are broken so we have no Dailies/Nightlies for our largest platform (see bug 1246894 comment #5).

Comment 4

[Stefan Sitter [:ssitter]]

FYI, my local Windows build using mozilla-build 2.1.0 and VS 2015 completed successfully. Maybe it depends on tooling chain or how the build system is setup too.

Comment 5

[Jorg K (CEST = GMT+2)]

Works for me using mozilla-build 2.1.0 and VS 2013, too.

Comment 6

[aleth [:aleth]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=09dca805e8f0

Comment 7

[Jorg K (CEST = GMT+2)]

(In reply to aleth [:aleth] from comment #6)
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=09dca805e8f0
That link doesn't work. There is no repo called "try". Do you mean one of these?
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=56c9ee3aff06
https://hg.mozilla.org/try-comm-central/rev/09dca805e8f0

Fantastic that you're looking at it! It's a real worry.

Comment 8

[aleth [:aleth]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4b70804437ca

Comment 9

[aleth [:aleth]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e3264aa30c57

Comment 10

[aleth [:aleth]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=29cb43f91f35

Comment 11

[aleth [:aleth]]

Attachment: Restore mysys-perl-wrapper for libical

Couldn't figure out a way to get around the relative path, but this worked on try.

Comment 12

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 8719178 [details] [diff] [review]
Restore mysys-perl-wrapper for libical

Review of attachment 8719178 [details] [diff] [review]:
-----------------------------------------------------------------

If the wrapper needs to be in mail/configure.in then I believe the msys-perl-wrapper should live in the mail/ directory too. We may also have to put it in mailnews so building Lightning with Seamonkey still works.

Another option would be to rewrite those perl scripts in python, I have one of them ported.

Comment 13

[aleth [:aleth]]

(In reply to Philipp Kewisch [:Fallen] from comment #12)
> If the wrapper needs to be in mail/configure.in then I believe the
> msys-perl-wrapper should live in the mail/ directory too. We may also have
> to put it in mailnews so building Lightning with Seamonkey still works.

I don't understand this comment. The patch here modifies mail/configure.in and suite/configure.in, so SM should be fine. Putting the wrapper script with the libical scripts that require it means anyone building Lightning can find it. An alternative location would be mailnews/build, but that seems arbitrary.

> Another option would be to rewrite those perl scripts in python, I have one
> of them ported.

Ah, if you are doing that, that would be more elegant :-) I was merely attempting to fix the bustage...

Comment 14

[Intermittent Failures Robot]

24 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* comm-central: 24

Platform breakdown:
* windowsxp: 22
* windows8-64: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1247282&startday=2016-02-08&endday=2016-02-14&tree=all

Comment 15

[Jorg K (CEST = GMT+2)]

Fallen, can we please make some progress here.
As I see it, the wrapper is called in mail/configure.in and suite/configure.in. If you want the wrapper itself to be duplicated into these two locations instead of having it once in calendar/libical/scripts/msys-perl-wrapper, then please lets do this and get the bustage fixed. IMHO a more elegant solution can wait.

Comment 16

[Philipp Kewisch [:Fallen][📱📆]]

(In reply to aleth [:aleth] from comment #13)
> (In reply to Philipp Kewisch [:Fallen] from comment #12)
> > If the wrapper needs to be in mail/configure.in then I believe the
> > msys-perl-wrapper should live in the mail/ directory too. We may also have
> > to put it in mailnews so building Lightning with Seamonkey still works.
> 
> I don't understand this comment. The patch here modifies mail/configure.in
> and suite/configure.in, so SM should be fine. Putting the wrapper script
> with the libical scripts that require it means anyone building Lightning can
> find it. An alternative location would be mailnews/build, but that seems
> arbitrary.
Sorry, I missed the fact that it is in both configure.ins.


(In reply to Jorg K (GMT+1) from comment #15)
> Fallen, can we please make some progress here.
> As I see it, the wrapper is called in mail/configure.in and
> suite/configure.in. If you want the wrapper itself to be duplicated into
> these two locations instead of having it once in
> calendar/libical/scripts/msys-perl-wrapper, then please lets do this and get
> the bustage fixed. IMHO a more elegant solution can wait.

I don't need the script duplicated, but moving the one script to more general location than calendar/libical/scripts would be great. mailnews/build would be fine for me, or you could put it into /build and add it to the exclusion list for check-sync-dirs.

I have 2 of the 4 scripts ported to python, I don't have time this evening to complete the work, but maybe tomorrow. If you really want the bustage to go away, I'd be ok with taking this as a temporary fix, I think it should be no problem to move it to build/ or mailnews/build though.

Comment 17

[Jorg K (CEST = GMT+2)]

I think we want the bustage to go away since we have no nightlies for Windows. Aleth can decide what he wants to do. There is no harm in landing a fix that we back out in two days.

Comment 18

[aleth [:aleth]]

https://hg.mozilla.org/comm-central/rev/f46004b3e9a6b6ac9f73a3a9897b277caff6ef29
Bug 1247282 - Restore mysys-perl-wrapper for libical. rs=Fallen

Comment 19

[aleth [:aleth]]

> I don't need the script duplicated, but moving the one script to more
> general location than calendar/libical/scripts would be great.
> mailnews/build would be fine for me, or you could put it into /build and add
> it to the exclusion list for check-sync-dirs.

Fwiw, I originally put the script into calendar/libical because I was under the impression that libical was going to be removed "soon" and I wanted to ensure this script would die with it. But as you're going to replace it with python goodness in a few days anyway, let's put it in mailnews ;)