991449 - TBPL Windows builds fail due to excessively long path names

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Joshua Cranmer [:jcranmer]]

Attachment: Shrink path lengths in Unified builds

... but not on mozilla-central since comm-central has slightly longer paths.

cc-rework should solve the disparity problem for the good (indeed, the offending build did work on a push to alder). For the time being, shrinking the prefix name of Unified build files should keep the problem at bay until cc-rework actually lands.

I'm testing the patch on Try, <https://tbpl.mozilla.org/?tree=Thunderbird-Try> should tell us if it works (assuming I've remembered the magic invocations to get applying patches on Windows working correctly).

Comment 1

[Mike Hommey [:glandium]]

Comment on attachment 8401051 [details] [diff] [review]
Shrink path lengths in Unified builds

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

::: python/mozbuild/mozbuild/backend/recursivemake.py
@@ +379,5 @@
>                          # On Windows, path names have a maximum length of 255 characters,
>                          # so avoid creating extremely long path names.
>                          unified_prefix = backend_file.relobjdir
> +                        if len(unified_prefix) > 20:
> +                            unified_prefix = unified_prefix[-20:].split('/', 1)[-1]

That seems a little short... I think i'd rather you used pymake until ccrework lands.

Comment 2

[Joshua Cranmer [:jcranmer]]

(In reply to Mike Hommey [:glandium] from comment #1)
> That seems a little short... I think i'd rather you used pymake until
> ccrework lands.

We are using pymake. It's the linker that's crashing here.

Comment 3

[Gregory Szorc [:gps]]

Comment on attachment 8401051 [details] [diff] [review]
Shrink path lengths in Unified builds

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

Does anyone really care that much about the prefixed path length? I don't think it's a huge deal. So r+.

I would also accept a follow-up that changes the prefix from "Unified" to "U" (or something).

And, yes, it sucks we have to do this hack.

Comment 4

[Joshua Cranmer [:jcranmer]]

Pushed: http://hg.mozilla.org/integration/mozilla-inbound/18cf30214a10

Comment 5

[Mike Hommey [:glandium]]

(In reply to Gregory Szorc [:gps] from comment #3)
> Comment on attachment 8401051 [details] [diff] [review]
> Shrink path lengths in Unified builds
> 
> Review of attachment 8401051 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Does anyone really care that much about the prefixed path length? I don't
> think it's a huge deal. So r+.

That seriously increases the chances of having many files with the same name, adding more confusion.

Comment 6

[Mike Hommey [:glandium]]

(In reply to Joshua Cranmer [:jcranmer] from comment #2)
> (In reply to Mike Hommey [:glandium] from comment #1)
> > That seems a little short... I think i'd rather you used pymake until
> > ccrework lands.
> 
> We are using pymake. It's the linker that's crashing here.

How come this wasn't a problem before?

Comment 7

[Mike Hommey [:glandium]]

Oh I see. New stuff in webrtc. I think the problem with webrtc is more the ridiculously long paths than the unified file length. I think this should be reverted, and webrtc paths be shortened instead.

Comment 8

[Mike Hommey [:glandium]]

seriously: remote_bitrate_estimator\remote_bitrate_estimator_components_rbe_components

Comment 9

[Mike Hommey [:glandium]]

(In reply to Mike Hommey [:glandium] from comment #5)
> That seriously increases the chances of having many files with the same
> name, adding more confusion.

Actually not since we keep the end, but i still stand by comment 7.

Comment 10

[Joshua Cranmer [:jcranmer]]

It's definitely not a long term solution, but it is a simple patch which would let us reopen comm-central and should hold until cc-rework removes the longer paths in comm-central.

On the other hand, maybe we should make moz.build error if there is a filename in SOURCES whose length (relative to topobjdir) is 100 characters or longer.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/18cf30214a10

Comment 12

[Magnus Melin [:mkmelin]]

Grr, target milestones are in the wrong order :/