Closed
Bug 936899
Opened 11 years ago
Closed 11 years ago
Build all of the uconv library in unified mode
Categories
(Core :: Internationalization, defect)
Core
Internationalization
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
References
(Blocks 1 open bug)
Details
(Whiteboard: [qa-])
Attachments
(1 file)
(deleted),
patch
|
smontagu
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Assignee | ||
Comment 1•11 years ago
|
||
Assignee | ||
Comment 2•11 years ago
|
||
Assignee: nobody → ehsan
Blocks: includehell
Assignee | ||
Updated•11 years ago
|
Attachment #829873 -
Flags: review?(smontagu)
Updated•11 years ago
|
Attachment #829873 -
Flags: review?(smontagu) → review+
Assignee | ||
Comment 3•11 years ago
|
||
Comment 4•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Comment 5•11 years ago
|
||
I have three questions:
- Why hasn't this been reviewed by a build peer?
- Why not move EXPORTs as well, and get rid of all those moz.builds?
- Why not move everything in intl/uconv, avoiding all those "../"?
Assignee | ||
Comment 6•11 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #5)
> I have three questions:
> - Why hasn't this been reviewed by a build peer?
I thought that things that don't make substantial changes to moz.build files don't need those reviews. This patch just moves variables around basically. Is there anything you want me to change in the patch?
> - Why not move EXPORTs as well, and get rid of all those moz.builds?
We can do that, but that would be out of scope for this bug. I am not sure what the advantage of doing that is. Can you please elaborate?
> - Why not move everything in intl/uconv, avoiding all those "../"?
That's a question for Simon. :-)
Comment 7•11 years ago
|
||
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #6)
> We can do that, but that would be out of scope for this bug. I am not sure
> what the advantage of doing that is. Can you please elaborate?
It is actually confusing to have contents of a directory half used from the moz.build it contains and half used from another "random" moz.build (by random, i mean any moz.build that is not in the directory ancestry ; and that, in itself, is also confusing, thus my third point). In fact, I'd argue that we shouldn't have contents of a directory described elsewhere than a moz.build in that directory at all, and leave it to the build backend to do what's right (which brings back to the first point).
Comment 8•11 years ago
|
||
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #6)
> (In reply to Mike Hommey [:glandium] from comment #5)
> > - Why not move everything in intl/uconv, avoiding all those "../"?
>
> That's a question for Simon. :-)
I'm not quite sure what move you're proposing here. I don't want to lose the split into different subdirectories, but I would be in favour of making all the ucv* directories, and also util, subdirectories of src.
Comment 9•11 years ago
|
||
(In reply to Simon Montagu :smontagu from comment #8)
> I'm not quite sure what move you're proposing here.
Essentially, I was proposing to move intl/uconv/src/moz.build to intl/uconv/moz.build.
Updated•11 years ago
|
Whiteboard: [qa-]
You need to log in
before you can comment on or make changes to this bug.
Description
•