Closed Bug 991449 Opened 11 years ago Closed 11 years ago

TBPL Windows builds fail due to excessively long path names

Categories

(Thunderbird :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 31.0

People

(Reporter: jcranmer, Assigned: jcranmer)

Details

Attachments

(1 file)

... 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).
Attachment #8401051 - Flags: review?(mh+mozilla)
Attachment #8401051 - Flags: review?(gps)
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.
(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 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.
Attachment #8401051 - Flags: review?(gps) → review+
(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.
Attachment #8401051 - Flags: review?(mh+mozilla)
(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?
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.
seriously: remote_bitrate_estimator\remote_bitrate_estimator_components_rbe_components
(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.
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.
Assignee: nobody → Pidgeot18
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 32.0
Grr, target milestones are in the wrong order :/
Target Milestone: Thunderbird 32.0 → Thunderbird 31.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: