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

Status: RESOLVED FIXED

(Calendar :: Build Config, defect)

Description

[aleth [:aleth]]

Regression after the recent configure changes, spun out of Bug 1254987.

Comment 1

[aleth [:aleth]]

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.

Comment 2

[Stefan Sitter [:ssitter]]

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.

Comment 3

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

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.

Comment 4

[aleth [:aleth]]

(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

[Stefan Sitter [:ssitter]]

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.

Comment 6

[aleth [:aleth]]

(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.

Comment 7

[Jorg K (CEST = GMT+2)]

Attachment: 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.

Comment 8

[Jorg K (CEST = GMT+2)]

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

Comment 9

[Jorg K (CEST = GMT+2)]

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.

Comment 10

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

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.

Comment 11

[Jorg K (CEST = GMT+2)]

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?

Comment 12

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

"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+

Comment 13

[Jorg K (CEST = GMT+2)]

Attachment: Brute force approach (v2).

Here you go. I've only included the functions required. Only one (read_values_file) is used twice.

Comment 14

[Jorg K (CEST = GMT+2)]

Attachment: Remove perl wrapper from bug 1247282

Would you like to remove the perl wrapper as well?

Comment 15

[Richard Marti (:Paenglab)]

Try build with both patches applied: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=2aa1cf656719

Comment 16

[Jorg K (CEST = GMT+2)]

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).

Comment 17

[Jorg K (CEST = GMT+2)]

Raised bug 1259917 for the Windows opt build failure.

Comment 18

[Jorg K (CEST = GMT+2)]

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.

Comment 19

[Jorg K (CEST = GMT+2)]

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".

Comment 20

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

Ok, so what is the status on this now? You closed the bug, but the review is stil open?

Comment 21

[Jorg K (CEST = GMT+2)]

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.

Comment 22

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

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.

Comment 23

[Jorg K (CEST = GMT+2)]

> 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 ;-)

Comment 24

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

I didn't, sorry. It was late :-)