Closed
Bug 543382
Opened 15 years ago
Closed 15 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•15 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•15 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•15 years ago
|
Target Milestone: --- → Future
Comment 3•15 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•15 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•15 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•15 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•15 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•15 years ago
|
Attachment #430800 -
Flags: feedback?(sgautherie.bz) → feedback-
Reporter | ||
Comment 8•15 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•15 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•15 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•15 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•15 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•15 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•15 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•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•