Re: Reworking the comm-central build system

[Jens Hatlak]

Mark Banner wrote:
> We'd need mozilla-central's configure and a few other items to have some
> additional hooks so that we could still specify options for comm-central
> (e.g. building with ldap)

One thing that comes to my mind there is the Help viewer situation
(still lives in Toolkit but is only used by SM until either bug 425541
or bug 424130 is fixed).

Greetings,

Jens

--
Jens Hatlak <http://jens.hatlak.de/>
SeaMonkey Trunk Tracker <http://smtt.blogspot.com/>

[Siddharth Agarwal]

On 11-04-2011 18:13, Mark Banner wrote:
>
> However the primary issue we have with it is that it requires us to
> constantly port across build system changes from mozilla-central.

As someone who's done that -- yay!

[Mark Banner]

On 11/04/2011 17:25, Jens Hatlak wrote:
> Mark Banner wrote:
>> We'd need mozilla-central's configure and a few other items to have some
>> additional hooks so that we could still specify options for comm-central
>> (e.g. building with ldap)
>
> One thing that comes to my mind there is the Help viewer situation
> (still lives in Toolkit but is only used by SM until either bug 425541
> or bug 424130 is fixed).

That wouldn't be affected by this change.

Standard8

[Tony Mechelynck]

On 11/04/11 14:43, Mark Banner wrote:
> Since it was set up, the comm-central build system has served us well.

>
> However the primary issue we have with it is that it requires us to
> constantly port across build system changes from mozilla-central.
>

> I met with KaiRo, Ted and khuey last week with a view towards looking to
> improve the situation.
>
> We came up with the following proposal.
>
> tl;dr version: Make the comm-central parts be built underneath
> mozilla-central and add necessary hooks for configuring comm-central
> options.
>
> Relevant bugs to follow at the end of this email.
>
> Long version:
>
> If we can make direct use of the mozilla-central build system, then we
> don't need to copy it for the comm-central apps all the time.
>
> Therefore the proposal is that we move comm-central to be underneath
> mozilla-central (this does not mean that we will be inside
> mozilla-central). So the directory structure we have now is:
>
> /comm-central/mailnews
> /comm-central/mail
> /comm-central/mozilla/accessible
> /comm-central/mozilla/toolkit
> etc.
>
> where /mozilla/ is the directory where the hg clone of mozilla-central
> is held.
>
> Under the new system we'd have:
>
> /mozilla-central/accessible
> /mozilla-central/toolkit
> /mozilla-central/comm/mailnews
> /mozilla-central/comm/mail
> etc.

IIUC, this would mean that any existing comm-central clones (with a
mozilla/ subdir containing a mozilla-central clone) will have to be
thrown away, and replaced by a mozilla-central clone whose client.py
would (if building SeaMonkey or Thunderbird but not Firefox) pull-update
an underlying comm-central clone (and then in turn an ldap-SDK clone,
and for SeaMonkey also Chatzilla, Venkman and DOMi). Is that it? Or did
I misunderstand?

This new system is arguably what ought to have been done from the start,
since everyone starts at the same point with a mozconfig at the same
place including ac_add_options --enable-application=<appname> to make
the difference between the various applications. There must however have
been some reasons to do it the way it was done, with a mozilla-central
clone inside comm-central. Do these reasons not apply anymore?

Best regards,
Tony.
--
Barach's Rule:
An alcoholic is a person who drinks more than his own
physician.

[Mark Banner]

On 12/04/2011 06:45, Tony Mechelynck wrote:
> IIUC, this would mean that any existing comm-central clones (with a
> mozilla/ subdir containing a mozilla-central clone) will have to be
> thrown away, and replaced by a mozilla-central clone whose client.py
> would (if building SeaMonkey or Thunderbird but not Firefox) pull-update
> an underlying comm-central clone (and then in turn an ldap-SDK clone,
> and for SeaMonkey also Chatzilla, Venkman and DOMi). Is that it? Or did
> I misunderstand?

You could do it via some mv commands, we'll give more info when it happens.

> There must however have
> been some reasons to do it the way it was done, with a mozilla-central
> clone inside comm-central. Do these reasons not apply anymore?

I think at the time it was seen as the easiest way to do the split, and
its slightly easier to set it up to be pulled. Unfortunately, the
maintenance cost of that is too high.

Standard8

[Neil]

Mark Banner wrote:

> We'd need mozilla-central's configure and a few other items to have
> some additional hooks so that we could still specify options for

> comm-central (e.g. building with ldap), however ted and khuey agreed
> that it'd be a reasonable addition to do.

In particular, if we're going to continue using fatlibxul, we need some
way of propagating the variable list of extra components to
toolkit/library's Makefile, which means setting variables in
mozilla-central's configuration. At least with the current system we can
export shell variables from our configure which mozilla-central's
configure can then read.

--
Warning: May contain traces of nuts.

[Neil]

Indeed, as it required little or no changes on the m-c side; we just
treated it as a sort of libxul SDK.

> Unfortunately, the maintenance cost of that is too high.

Is it not possible to work around the problem by porting the
s/topsrcdir/MOZILLA_DIR/ changes to m-c's rules.mk so that we can use it
directly instead of having a copy?

[Justin Wood (Callek)]

On 4/15/2011 8:22 AM, Neil wrote:

> Mark Banner wrote:
>> Unfortunately, the maintenance cost of that is too high.
> Is it not possible to work around the problem by porting the
> s/topsrcdir/MOZILLA_DIR/ changes to m-c's rules.mk so that we can use it
> directly instead of having a copy?
>

It is possible, among other things to do something like that, but we're
not talking about *just* rules.mk, which is relatively in sync.

We're talking about autoconf.mk, config.mk, configure, etc.

And even with rules.mk if a change goes into m-c that breaks us (because
it touches files outside of rules.mk), we need a way to fix that. And
nevermind our current solution of using c-c to track multiple m-c repos,
it just wouldn't work if we tried to import rules.mk directly. Forcing
us to branch earlier than we would otherwise.

--
~Justin Wood (Callek)

[Robert Kaiser]

Tony Mechelynck schrieb:

> IIUC, this would mean that any existing comm-central clones (with a
> mozilla/ subdir containing a mozilla-central clone) will have to be
> thrown away, and replaced by a mozilla-central clone whose client.py
> would (if building SeaMonkey or Thunderbird but not Firefox) pull-update
> an underlying comm-central clone (and then in turn an ldap-SDK clone,
> and for SeaMonkey also Chatzilla, Venkman and DOMi). Is that it? Or did
> I misunderstand?

mozilla-central will not have a client.py that pulls our repos. It's
unsure how that would work, possibly we might need to replace client.py
with all-manual processes to pull in the other repos. Not sure if Mark
has a good idea there.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)

[Justin Wood (Callek)]

On 4/20/2011 12:06 PM, Robert Kaiser wrote:
> mozilla-central will not have a client.py that pulls our repos. It's
> unsure how that would work, possibly we might need to replace client.py
> with all-manual processes to pull in the other repos. Not sure if Mark
> has a good idea there.

In brief talk with ted/khuey they think us "hijacking" the m-c client.py
might be ok.

We have not delved into the details though.... And it is one of my last
tasks with the switch, so we shall see.

--
~Justin Wood (Callek)