195953 - Need configure flag for building camino

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Chris McAfee]

We need a configure flag for building camino, this will
let us ifdef through client.mk and Makefile.in to build
in the right directories.  Up until now we got away w/o this
because we were sitting on a branch.  On to the big leagues!

  --enable-camino  .. sets MOZ_BUILD_CAMINO=1 ?

Comment 1

[Chris McAfee]

phoenix has MOZ_PHOENIX, maybe we should be MOZ_CAMINO.

Phoenix uses env var?  Makes more sense to me to use a configure flag.

Comment 2

[hacker formerly known as [e-mail]]

Too many issues here:
1) setting a configure flag has absolutely no effect on client.mk, so
2) you have to set an env variable to pull the non-SeaMonkey portion of the source
3) I'm not really keen on configure options that do not work with our default
pull.  They lead to bogus bugreports and excessive hand-holding.
4) I don't think camino or phoenix should be incorporated into the Mozilla/gecko
build tree.  They should be clients of gecko, not a part of gecko itself.  We
should be adding ifdefs to turn off certain feature sets, not adding ifdefs for
the embedding client of the month that we're concerned about building.

Comment 3

[Jon Granrose]

seconding what cls said, esp. 4)

Comment 4

[Chris McAfee]

ok granrose & seawood, what's the suggested route here?
mozilla/camino.mk ?

Comment 5

[hacker formerly known as [e-mail]]

camino/camino.mk .  I see no need for these bits to reside underneath mozilla/
in the tree.  Let's take a page from the photon guys and incorporate gecko into
the camino build process rather than incorporating camino into the gecko build
process.

Comment 6

[Brian Ryner (not reading)]

Just to clarify, you're suggesting making camino a toplevel directory that sits
alongside mozilla, instead of the current mozilla/camino directory?

Comment 7

[hacker formerly known as [e-mail]]

That is correct.

Comment 8

[Conrad Carlen (not reading bugmail)]

I take back what I wrote to the camino list. I completely agree with comment 5.

Comment 9

[Brendan Eich [:brendan]]

New top-top-levels need to be run past [e-mail].  Please mail them with
this proposal.

Notice that mozilla/ hosts many apps, not just "Mozilla the app-suite [plus
phoenix, plus camino till now, which moved just the other week from chimera]". 
We have not yet populated mozilla/ beyond other-licenses, right?

What's photon? ;-)

/be

Comment 10

[timeless]

i'm not sure about we

http://bonsai.mozilla.org/rview.cgi?&cvsroot=/cvsroot&dir=/
Attic <- some content thanks to glazou
CVSROOT <- required, locked
README <- interesting historical documents
	
atwork <- amusing accidental checkin from kevin%perldap.org
buildtools <- windows/os2 build tools (useful) and tar (no idea)
l10nkits <- rick ellicot [netscape.com] 13 Apr 1998 First release of universal
localization program kits

macbuild <- is empty
mozilla <- ...
www <- contains home/ which is empty

certainly if we means people coordinating through [e-mail], then there
has been no use of / beyond /mozilla

i'm not sure i'd want to work on getting lxr to handle parent of mozilla, there
are currently some bounds checking problems (webtools-security) with it, i
suppose it might actually make things cleaner if we nested the mozilla directory
deeper, but ...

note, other-licenses is a child of mozilla, not a sibling:
http://bonsai.mozilla.org/rview.cgi?dir=mozilla%2Fother-licenses&rev=&module=default&cvsroot=%2Fcvsroot

otoh i can actually see some benefits in sticking projects outside of /mozilla.

photon is obviously not the qnx people who checked into cvs.mozilla.org
startling cls ;-)

Comment 11

[hacker formerly known as [e-mail]]

> Notice that mozilla/ hosts many apps, not just "Mozilla the app-suite [plus
> phoenix, plus camino till now, which moved just the other week from chimera]". 

There are other modules that can be pulled from mozilla/ , sure.  It's always
woe to those who think that 'cvs co mozilla' is a good idea.  However, most (if
not all?) of those modules have been there since 'The Beginning(tm)', are
usually related to the app-suite in some way (like a replacement for an existing
module) and/or not actively used (didn't timeless attempt to remove most of
mozilla/lib recently).  Those points do not apply to camino and our other recent
embedding/standalone efforts.  Btw, I rsync the cvs tree a couple of times a day
and I rarely see many changes outside of our extended app-suite world.  

> i'm not sure i'd want to work on getting lxr to handle parent of mozilla, there
> are currently some bounds checking problems (webtools-security) with it, i
> suppose it might actually make things cleaner if we nested the mozilla directory
> deeper, but ...

I've hacked our copy of lxr to handle source trees from / before.  It's not that
hard.  I may have even sent the changes Dawn's way but that was easily 2 years
ago.  I've always thought that assuming mozilla/ was the root of everything in
our world was just silly.  

Comment 12

[Brian Ryner (not reading)]

Attachment: first cut at mozilla/camino.mk

Comment 13

[hacker formerly known as [e-mail]]

Comment on attachment 117278 [details]
first cut at mozilla/camino.mk

The proposed build procedure is:
cvs co mozilla/client.mk
cvs co mozilla/camino.mk
make -f mozilla/camino.mk

?  Why the extra explicit cvs co ?  

MOZ_CO_TAG should be propagated to client.mk on checkout, as should
MOZ_CO_FLAGS & MOZ_CO_DATE.

The makefile isn't objdir ready.  Didn't Conrad fix camino to make it build
from objdirs? Maybe that was just the plugin?

Comment 14

[Brian Ryner (not reading)]

Nope, Camino doesn't build in an objdir, though we don't think that would be too
hard to fix.

Comment 15

[Conrad Carlen (not reading bugmail)]

> Maybe that was just the plugin?

That was PPEmbed & Cocoa embedding samples. After doing that, I spoke with
bryner friday about doing the same for Camino. The only additional hurdle is
that the part in allmakefiles.sh which refers mozilla/camino/Makefile would have
to be conditionalized. We decided that the camino makefile could set a variable
which could be used in allmakefiles.sh. Once we have that, making it work with
objdir builds is simple - using the pattern I've been using elsewhere.

Comment 16

[hacker formerly known as [e-mail]]

camino uses allmakefiles.sh ?  I didn't think that was the case (at least on the
trunk).

Comment 17

[Brian Ryner (not reading)]

Also, MOZ_CO_DATE/TAG/FLAGS shouldn't need to be explicitly passed to client.mk;
they'll be present in the environment.

Comment 18

[Brian Ryner (not reading)]

Attachment: camino.mk

don't require explicit checkout of client.mk

Comment 19

[hacker formerly known as [e-mail]]

That's lame.  If I'm going to use those variables, they are set on the make
commandline, never in the enviornment.  IIRC, unless you export the variables
inside the makefile, setting them on the camino.mk commandline will not set them
for the client.mk environment.

Comment 20

[Brian Ryner (not reading)]

Attachment: camino.mk

Comment 21

[Brian Ryner (not reading)]

Comment on attachment 119902 [details]
camino.mk

this one exports the MOZ_CO_ variables.

Comment 22

[Brian Ryner (not reading)]

checked in.

Comment 23

[Simon Fraser [no longer active]]

How does this play in an objdir build? And is this the recommended way to build
now? Should we update the build instructions, and tinderboxes?