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

RESOLVED FIXED in 5.0

Status

Calendar
Build Config
--
blocker
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: aleth, Assigned: Jorg K (GMT+2))

Tracking

Lightning 5.0

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

a year ago
Regression after the recent configure changes, spun out of Bug 1254987.
(Reporter)

Comment 1

a year ago
This is an ugly hack that broke. In bug 1247282, Fallen mentioned he had a WIP of a python replacement. It might be easier to complete that WIP than try to rescue the msys-perl-wrapper.
Flags: needinfo?(philipp)

Comment 2

a year ago
From Bug 1254987 Comment 91:

According to the log it seems that perl might be called directly instead of being called through the msys-perl-wrapper that converts the include paths:
> 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

Is the fix from Bug 1247282 still in place and working?

My private build on Windows finished successfully without this error. Maybe it is related to what mozilla-build version is used or how the build is setup or started or something else.
(Reporter)

Updated

a year ago
Blocks: 1254987
Unfortunately the python code got lost because I excluded comm-central from my time machine backups and moved to a new machine :-/ Need to start that over again.
(Reporter)

Comment 4

a year ago
(In reply to Stefan Sitter from comment #2)
> From Bug 1254987 Comment 91:
> 
> According to the log it seems that perl might be called directly instead of
> being called through the msys-perl-wrapper that converts the include paths:
> > 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
>
> My private build on Windows finished successfully without this error.

What do the corresponding lines in your local log look like?

Comment 5

a year ago
It seems they are actually the same except the source / obj path. My build:

> mozmake.EXE[3]: Entering directory 'd:/dev/comm-central/src/obj-i686-pc-mingw32/calendar/libical/src/libical'
> C:/mozilla-build/msys/bin/perl.EXE -Id:/dev/comm-central/src/calendar/libical/src/libical/../../scripts  d:/dev/comm-central/src/calendar/libical/src/libical/../../scripts/mkderivedvalues.pl \
>          -i d:/dev/comm-central/src/calendar/libical/src/libical/icalderivedvalue.h.in -h d:/dev/comm-central/src/calendar/libical/src/libical/../../design-data/value-types.csv > icalderivedvalue.h

Comm-central build

> 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

I have no idea why it works for me. From the logs I only see that on the comm-central server build the inc path changes from "c:/builds" to "c /builds" causing the failure.
(Reporter)

Updated

a year ago
Severity: normal → blocker
(Reporter)

Comment 6

a year ago
(In reply to Stefan Sitter from comment #5)
> I have no idea why it works for me. From the logs I only see that on the
> comm-central server build the inc path changes from "c:/builds" to "c
> /builds" causing the failure.

No idea, but you didn't see the problem last time it broke either ;) Bug 1247282 comment 4.
(Assignee)

Comment 7

a year ago
Created attachment 8734544 [details] [diff] [review]
Brute force approach.

In absence of a fix to the perl problem, could be land a *temporary* workaround to get the trees open again?

This patch removes the "require" (which doesn't work due to inclusion problems) and pastes the file content instead.
(Assignee)

Comment 8

a year ago
Here's a try for it:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=7beac4b6548a
(Reporter)

Updated

a year ago
Attachment #8734544 - Flags: review?(philipp)
(Assignee)

Comment 9

a year ago
Magnus, do you think this is acceptable as a temporary fix? We could be (partly) green on Windows.

Fallen can back it out and do something better later.
Flags: needinfo?(mkmelin+mozilla)
Comment on attachment 8734544 [details] [diff] [review]
Brute force approach.

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

I don't see the need for minifying that code, you can just use the expanded version.
Attachment #8734544 - Flags: review?(philipp) → review-
(Assignee)

Comment 11

a year ago
One line change, one line out, one line in ;-)

I was meant as a *temporary* fix to be backed out later when you switch this to python and we remove the wrapper which has now stopped working.

So how should we proceed?
Flags: needinfo?(philipp)
Flags: needinfo?(mkmelin+mozilla)
"temporary" fixes often stay around longer. I lost the python code due to it not being included in my backup, so I'll have to start over. Just include those functions unminified and I'll give r+
(Assignee)

Comment 13

a year ago
Created attachment 8734912 [details] [diff] [review]
Brute force approach (v2).

Here you go. I've only included the functions required. Only one (read_values_file) is used twice.
Attachment #8734544 - Attachment is obsolete: true
Attachment #8734912 - Flags: review?(philipp)
(Assignee)

Comment 14

a year ago
Created attachment 8735098 [details] [diff] [review]
Remove perl wrapper from bug 1247282

Would you like to remove the perl wrapper as well?
Attachment #8735098 - Flags: review?(philipp)
Try build with both patches applied: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=2aa1cf656719
(Assignee)

Comment 16

a year ago
Thanks! Sadly the opt version doesn't build, error is:

configure:20278: cl -c  -TC -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -arch:IA32 -FS -wd4244 -wd4267 -wd4819 -we4553 -Werror  conftest.c 1>&5
cl : Command line error D8021 : invalid numeric argument '/Werror'
configure: failed program was:
#line 20271 "configure"

We could already see this here:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=7beac4b6548a

Debug should build, and tests should be mostly green, one new failure being looked at in bug 1259854 (with two more failures which arose during the two weeks of bustage already resolved in the last 24 hours: bug 1259855 and bug 1259815).
(Assignee)

Comment 17

a year ago
Raised bug 1259917 for the Windows opt build failure.
(Assignee)

Comment 18

a year ago
Included functions. Tabs and trailing spaces removed. The landed patch is therefore different from the attached one due to white-space.
https://hg.mozilla.org/comm-central/rev/dd691b216fc1 - r+ as per comment #12.

Removed wrapper from bug 1247282 as it's not needed and more.
https://hg.mozilla.org/comm-central/rev/a6c06327a4b9

Sorry, but one day we need to get back up and running.
(Assignee)

Comment 19

a year ago
Let's close this bug and file another one to fix it properly.

As Philipp said in comment #12: "temporary" fixes often stay around longer.
So no point in keeping this open "longer".
Assignee: nobody → mozilla
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Target Milestone: --- → 5.0
Version: unspecified → Lightning 5.0
Ok, so what is the status on this now? You closed the bug, but the review is stil open?
Flags: needinfo?(mozilla)
(Assignee)

Comment 21

a year ago
Yes, this was landed two days ago as per comment #18 since we needed to get up an running again after more than two weeks of bustage. A lot of stuff has landed since then.

I suggest you rs+ both patches. Or if you hate what I did, I can land another patch to change the comments I put. Other than that, I followed your instructions to include the functions (comment #12).

And the wrapper wasn't necessary any more, so it got removed in order not to carry yet more vestiges of the past around.
Flags: needinfo?(mozilla)
Comment on attachment 8734912 [details] [diff] [review]
Brute force approach (v2).

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

Thanks for the clarification! Looks fine to me aside from the trailing whitespaces, but I don't think it is worth a followup commit.
Attachment #8734912 - Flags: review?(philipp) → review+
Attachment #8735098 - Flags: review?(philipp) → review+
(Assignee)

Comment 23

a year ago
> Thanks for the clarification! Looks fine to me aside from the trailing
> whitespaces, but I don't think it is worth a followup commit.
Oh, you didn't read comment #18, or it wasn't clear: What was checked in had the trailing white-space and the tabs removed. It's all good ;-)
I didn't, sorry. It was late :-)
You need to log in before you can comment on or make changes to this bug.