Closed
Bug 1247282
Opened 8 years ago
Closed 8 years ago
Libical build error when invoking mkderivedvalues.pl perl script [mozmake.exe[5]: *** [icalderivedvalue.h] Error 2]
Categories
(Calendar :: Internal Components, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
4.9
People
(Reporter: ssitter, Assigned: aleth)
References
Details
Attachments
(1 file)
2.79 KB,
patch
|
Fallen
:
feedback+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•8 years ago
|
OS: Unspecified → Windows
Hardware: Unspecified → All
Assignee | ||
Updated•8 years ago
|
Severity: normal → blocker
Assignee | ||
Comment 1•8 years ago
|
||
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?
Flags: needinfo?(ssitter)
Reporter | ||
Comment 2•8 years ago
|
||
Maybe. Someone familiar with perl or makefile or both should take a look.
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(ssitter)
Comment 3•8 years ago
|
||
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).
Flags: needinfo?(mh+mozilla)
Reporter | ||
Comment 4•8 years ago
|
||
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•8 years ago
|
||
Works for me using mozilla-build 2.1.0 and VS 2013, too.
Assignee | ||
Comment 6•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=09dca805e8f0
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(mh+mozilla)
Comment 7•8 years ago
|
||
(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.
Assignee | ||
Comment 8•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4b70804437ca
Assignee | ||
Comment 9•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e3264aa30c57
Assignee | ||
Comment 10•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=29cb43f91f35
Assignee | ||
Comment 11•8 years ago
|
||
Couldn't figure out a way to get around the relative path, but this worked on try.
Attachment #8719178 -
Flags: review?(philipp)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → aleth
Status: NEW → ASSIGNED
Comment 12•8 years ago
|
||
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.
Attachment #8719178 -
Flags: review?(philipp) → feedback+
Assignee | ||
Comment 13•8 years ago
|
||
(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 hidden (Intermittent Failures Robot) |
Comment 15•8 years ago
|
||
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.
Flags: needinfo?(philipp)
Comment 16•8 years ago
|
||
(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.
Flags: needinfo?(philipp)
Comment 17•8 years ago
|
||
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.
Assignee | ||
Comment 18•8 years ago
|
||
https://hg.mozilla.org/comm-central/rev/f46004b3e9a6b6ac9f73a3a9897b277caff6ef29 Bug 1247282 - Restore mysys-perl-wrapper for libical. rs=Fallen
Assignee | ||
Comment 19•8 years ago
|
||
> 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 ;)
Reporter | ||
Updated•8 years ago
|
Assignee | ||
Updated•8 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.9
You need to log in
before you can comment on or make changes to this bug.
Description
•