Closed
Bug 543382
Opened 11 years ago
Closed 11 years ago
Port |Bug 467862 - Build system should support building both a static and a shared library from the same Makefile| to comm-central
Categories
(MailNews Core :: Build Config, defect)
MailNews Core
Build Config
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: sgautherie, Assigned: Callek)
References
()
Details
Attachments
(1 file)
4.43 KB,
patch
|
kairo
:
review+
standard8
:
superreview+
sgautherie
:
feedback-
|
Details | Diff | Splinter Review |
Fwiw, the only current explicit use is { /mozilla/js/src/Makefile.in * line 88 -- STATIC_LIBRARY_NAME = js_static }
Flags: in-testsuite-
![]() |
||
Comment 1•11 years ago
|
||
Right, but if I read the original bug correctly, this should let us run xpcshell against a static binary - if so, Standard8 should be interested, I guess ;-)
Assignee | ||
Comment 2•11 years ago
|
||
Yes, from what I've read and seen on this; it is worth porting; even if c-c has no consumers of its use yet. We could likely want some in the future.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Updated•11 years ago
|
Target Milestone: --- → Future
Comment 3•11 years ago
|
||
We don't need a future milestone on this. It can be ported at any time. IMO a future milestone is only really necessary for things we really don't intend to do at this time because we're not ready.
Target Milestone: Future → ---
Reporter | ||
Comment 4•11 years ago
|
||
(In reply to comment #3) > We don't need a future milestone on this. It can be ported at any time. IMO a Agreed. It was not meant to "require" a new milestone, but just that we have no need to port this until it's eventually needed. (Just like setting it to P5, but I'm not using 'Importance'.) > future milestone is only really necessary for things we really don't intend to > do at this time because we're not ready. Afaik, I (and now Callek) am the only developer working on bug 506493, so I'm sad you can't just let me(/us) do it my/our way :-< That said, as it's not Future anymore, I'd love if you could assign someone to this bug...
Assignee | ||
Comment 5•11 years ago
|
||
(In reply to comment #4) > (In reply to comment #3) > > future milestone is only really necessary for things we really don't intend to > > do at this time because we're not ready. > > Afaik, I (and now Callek) am the only developer working on bug 506493, so I'm > sad you can't just let me(/us) do it my/our way :-< I was not for or against setting the "future" milestone, I usually leave those things default unless there is a *reason* to set them. in this case there was no reason so I agree with mark's statements. Please don't put words in my mouth. > That said, as it's not Future anymore, I'd love if you could assign someone to > this bug... That said, I don't see a need to "force" someone to take this bug, its not a blocker. Most of the c-c build system team is volunteer. And I will likely work on this before next release of TB or SM (if no-one beats me to it). I do not wish to be assigned until I *start* work on bugs though, so the current state of assignee, flags, etc. are correct.
Reporter | ||
Comment 6•11 years ago
|
||
(In reply to comment #5) > Please don't put words in my mouth. I was not trying to put words in your mouth: my comment was more a "why should anyone else but me cares?". > That said, I don't see a need to "force" someone to take this bug, its not a > blocker. Well, it looked like to me that Mark seemed to care that this bug gets resolved sooner than later...
Assignee | ||
Comment 7•11 years ago
|
||
Assignee: nobody → bugspam.Callek
Status: NEW → ASSIGNED
Attachment #430800 -
Flags: superreview?(bugzilla)
Attachment #430800 -
Flags: review?(kairo)
Attachment #430800 -
Flags: feedback?(sgautherie.bz)
Reporter | ||
Updated•11 years ago
|
Attachment #430800 -
Flags: feedback?(sgautherie.bz) → feedback-
Reporter | ||
Comment 8•11 years ago
|
||
Comment on attachment 430800 [details] [diff] [review] v1 -- Port bug and its bustage fix. Bug 534408 should make this port simpler. (I didn't read further...) Any reason not to wait for it?
Assignee | ||
Comment 9•11 years ago
|
||
(In reply to comment #8) > (From update of attachment 430800 [details] [diff] [review]) > > Bug 534408 should make this port simpler. (I didn't read further...) > Any reason not to wait for it? If that bug is *also* porting this, no reason not to wait. If it is NOT porting this, I'd rather get this in and do more in "other ports".
Reporter | ||
Comment 10•11 years ago
|
||
(In reply to comment #9) > If that bug is *also* porting this, no reason not to wait. If it is NOT porting I don't know yet, but I assume that bug won't port this one for free. > this, I'd rather get this in and do more in "other ports". What's the hurry? Porting in the wrong order just makes things more complex: more porting, more cleanup. (Though you're not the only one to do that :-/) Besides, I'm concerned that Standard8 spends time on things like this (which afaik we don't need yet) instead of on my blocking ports (like debug packaged tests bustage bugs)...
![]() |
||
Comment 11•11 years ago
|
||
Comment on attachment 430800 [details] [diff] [review] v1 -- Port bug and its bustage fix. >@@ -840,9 +834,9 @@ ifdef EXPORT_LIBRARY > ifdef IS_COMPONENT > ifdef BUILD_STATIC_LIBS > ifdef MOZILLA_1_9_2_BRANCH >- @$(PERL) -I$(MOZILLA_DIR)/config $(MOZILLA_DIR)/config/build-list.pl $(FINAL_LINK_COMPS) $(LIBRARY_NAME) >+ @$(PERL) -I$(MOZILLA_DIR)/config $(MOZILLA_DIR)/config/build-list.pl $(FINAL_LINK_COMPS) $(STATIC_LIBRARY_NAME) > else >- @$(PYTHON) $(MOZILLA_DIR)/config/buildlist.py $(FINAL_LINK_COMPS) $(LIBRARY_NAME) >+ @$(PYTHON) $(MOZILLA_DIR)/config/buildlist.py $(FINAL_LINK_COMPS) $(STATIC_LIBRARY_NAME) > endif > ifdef MODULE_NAME > ifdef MOZILLA_1_9_2_BRANCH nit: don't change the indentation in the |ifdef MOZILLA_1_9_2_BRANCH|, kepp the tab intact.
Attachment #430800 -
Flags: review?(kairo) → review+
Assignee | ||
Comment 12•11 years ago
|
||
(In reply to comment #11) > nit: don't change the indentation in the |ifdef MOZILLA_1_9_2_BRANCH|, kepp the > tab intact. Gyah that was actually my local editor screwing up, I'll fix by checkin. Just waiting for Mark now.
Comment 13•11 years ago
|
||
Comment on attachment 430800 [details] [diff] [review] v1 -- Port bug and its bustage fix. Looks reasonable, although I've not tried it out.
Attachment #430800 -
Flags: superreview?(bugzilla) → superreview+
Assignee | ||
Comment 14•11 years ago
|
||
(In reply to comment #12) > (In reply to comment #11) > > nit: don't change the indentation in the |ifdef MOZILLA_1_9_2_BRANCH|, kepp the > > tab intact. > > Gyah that was actually my local editor screwing up, I'll fix by checkin. Just > waiting for Mark now. ...and actually this shouldn't even have been a nit, it is a breaking change as this is a rule's command! :/ (I failed tab-conversion in two spots actually) Anyway... Pushed as: http://hg.mozilla.org/comm-central/rev/9979fbcff2c9
Assignee | ||
Updated•11 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•