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)
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 31.0
People
(Reporter: jcranmer, Assigned: jcranmer)
Details
Attachments
(1 file)
1.47 KB,
patch
|
gps
:
review+
|
Details | Diff | Splinter Review |
... 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).
Assignee | ||
Updated•11 years ago
|
Attachment #8401051 -
Flags: review?(mh+mozilla)
Attachment #8401051 -
Flags: review?(gps)
Comment 1•11 years ago
|
||
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.
Assignee | ||
Comment 2•11 years ago
|
||
(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•11 years ago
|
||
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+
Assignee | ||
Comment 4•11 years ago
|
||
Comment 5•11 years ago
|
||
(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.
Updated•11 years ago
|
Attachment #8401051 -
Flags: review?(mh+mozilla)
Comment 6•11 years ago
|
||
(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•11 years ago
|
||
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•11 years ago
|
||
seriously: remote_bitrate_estimator\remote_bitrate_estimator_components_rbe_components
Comment 9•11 years ago
|
||
(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.
Assignee | ||
Comment 10•11 years ago
|
||
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•11 years ago
|
||
Assignee: nobody → Pidgeot18
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 32.0
Comment 12•11 years ago
|
||
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.
Description
•