Fix build to allow building command line tools without svrcore

RESOLVED FIXED

Status

RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: richm, Assigned: richm)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

13 years ago
You should be able to build the command line tools without svrcore.  This fix should not affect the client builds but I'd like to get it in the client branch just to keep the trees in sync.
(Assignee)

Comment 1

13 years ago
Created attachment 220703 [details]
files for fix
(Assignee)

Comment 2

13 years ago
Created attachment 220704 [details]
diffs for fix
(Assignee)

Comment 3

13 years ago
Can I get a review?  For HEAD and client branch?  The fix is pretty simple and should not affect the client builds, but I'd like to get the fix on the client branch just to keep them in sync - I'm a big fan of double checkins rather than attempt to merge at some later date.
(In reply to comment #0)
> You should be able to build the command line tools without svrcore.  This fix
> should not affect the client builds but I'd like to get it in the client branch
> just to keep the trees in sync.

(In reply to comment #3)
> Can I get a review?  For HEAD and client branch?  The fix is pretty simple and
> should not affect the client builds, but I'd like to get the fix on the client
> branch just to keep them in sync - I'm a big fan of double checkins rather than
> attempt to merge at some later date.

I don't see that we need to keep the trees in sync - the point of the client branch that the mozilla products use is that it is stable and away from main c-sdk development. We should only be putting patches on the client branch that are required as major bug fixes (e.g. build failures/big problems) and only once its had some time on trunk where people have had time to test it and ensure there are no problems. Yes it means we may get some problems with merging at a later date - but that's one of the risks with a branch. The basic rule is anything that goes in for the client branch must go in on the trunk, but if it goes in on trunk it doesn't necessarily need to go in on the client branch.

Additionally we need to be careful as the client branch may be used in releases (though admittedly I'm not quite sure how exactly releases work) so checkins may not be allowed all the time.

Comment 5

13 years ago
Comment on attachment 220704 [details]
diffs for fix

The changes look fine.
Attachment #220704 - Flags: review+

Comment 6

13 years ago
(In reply to comment #4)
> (In reply to comment #0)
> I don't see that we need to keep the trees in sync - the point of the client
> branch that the mozilla products use is that it is stable and away from main
> c-sdk development....

I agree with what you are saying, but we also need to have a plan for keeping the trees in sync, e.g., "merge (or reset branch tag) after each major release of TBird."  I leave it to the application teams to say what makes the most sense, but we don't want things to drift apart for as long as they have historically (that adds more risk when a new branch is cut).

Comment 7

13 years ago
-> Rich.
Assignee: mcs → richm
(Assignee)

Comment 8

13 years ago
Fixed:
Checking in configure;
/cvsroot/mozilla/directory/c-sdk/configure,v  <--  configure
new revision: 5.51; previous revision: 5.50
done
Checking in configure.in;
/cvsroot/mozilla/directory/c-sdk/configure.in,v  <--  configure.in
new revision: 5.50; previous revision: 5.49
done
Checking in config/autoconf/svrcore.m4;
/cvsroot/mozilla/directory/c-sdk/config/autoconf/svrcore.m4,v  <--  svrcore.m4
new revision: 5.5; previous revision: 5.4
done
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.