182076 - Build with --enable-calendar by default.

Status: VERIFIED WONTFIX

(SeaMonkey :: Build Config, defect)

Description

[Mike Potter]

This bug is going to be used to track the integration of calendar into the
default 1.3 alpha builds.

Comment 1

[Asa Dotzler [:asa]]

Mike, 1.3a closes one week from today. Is this still doable?

Comment 2

[Mike Potter]

Yes, I think it is.  The calendar is currently running on Windows, Linux, Mac OS
X and Mac OS 9.  There are some changes that have to be done in order to support
Mac OS 9, as discussed in bug 146310.
I am not quite sure about what needs to be changed to get into the default
builds, but it is running and builds on all the platforms. I believe it is just
a matter of turning it on (which is probably not as easy as it sounds! :) )

Comment 3

[Peter Lairo]

You guys do realize that calendar is about as polished as mozilla was two years
ago? It will be a big contrast to the rest of mozilla.

Having said that, I'm glad it's coming in. :)

Comment 4

[david avery]

i haven't followed all the libical stuff for a while, but to integrate into the
default build I would thing that libical will have to be built as part of a
"make alldep" and the library file added to packaging, and you may need to deal
with the issues that the SVG people have dealt with concerning a
non-tri-licensed library.

i think you will have to do like the SVG folks did and add "mozilla style"
Makefiles to libical

Comment 5

[hacker formerly known as [e-mail]]

Can someone from staff give an official definition for "default build"?  Are we
talking about the tinderboxes, ./configure or the nightlies
(http://www.mozilla.org/build/distribution.html) ?  If only the tier-1 platforms
have been tested, then I'm a bit leary about turning this on by default in
configure as it could turn the entire ports tree red.

What's the deal with libical?  What changes does it contain that haven't been
sent to the upstream maintainer?  If at all possible, we should keep these 3rd
party dependencies as an external build requirement.

Comment 6

[Frederic Bezies]

As I used CVS today, I saw there were a makefile.in added in /mozilla/calendar.

Using --enable-calendar option, calendar was built without any problem.

Should this bug be marked resolved fixed or not ?

Comment 7

[hacker formerly known as [e-mail]]

No, the bug should not be closed out as the plan (last I heard) was to turn the
code on by default.  However, we cannot do that until the entire module has been
super-reviewed.

Comment 8

[Frederic Bezies]

I was just asking. I don't want to bother anybody :-)

But compiling calendar is a good news for somebody like me who doesn't have a
lot of free time ;-)

Comment 9

[Robert Kaiser]

The Bug Summary talks of "1.3 Alpha Builds" - should this changed to "Beta", or
should we just say "default builds" (would be best IMO)?

Comment 10

[Mike Potter]

*** Bug 138192 has been marked as a duplicate of this bug. ***

Comment 11

[Frederic Bezies]

Since today, building calendar (using --enable-calendar) is broken.

There were a lot of updates yesterday, and maybe they can explain bug 187763.

When I am trying to build calendar, in libxpical option, I have something like
90 warnings and building is stopped saying :

"xpical.dll : fatal error LNK1120: 98 unresolved externals
make[4]: *** [xpical.dll] error 96
make[4]: Leaving directory '/cygdrive/c/mozilla/calendar/libxpical'
make[3]: *** [libs] Error 2
make[3]: Leaving directory '/cygdrive/c/mozilla/calendar/'
make[2]: *** [tier_98] Error 2
make[2]: Leaving directory '/cygdrive/c/mozilla/'
make[1]: *** [default] Error 2
make[1]: Leaving directory '/cygdrive/c/mozilla/'
make: *** [build] Error 2"

Any idea ?

Is bug 187763 a blocker for this bug ?

Comment 12

[Robert Kaiser]

what's the status here? any chance to get the switch flipped in 1.4 cycle still?

Comment 13

[Aleksander Adamowski]

Hello? 1.4 has just been released, trunk is relaxed, now it is good time to
check in big and risky new features like this. Would be lovely to finally get
calendar merged with the main tree. Testing would be easier and more efficient...

Comment 14

[Adam D. Moss]

While it would be nice to turn this 'on' by default, assuming that despite being
distributed separately the various Mozilla apps will still be build from the
same build process (a BIG assumption), I suspect that this bug becomes a WONTFIX
with the event of the new timeline and the plans of dis-integration of the Moz
app suite in the 1.5 period.  It makes sense.

Comment 15

[Brant Gurganus]

This, indeed, is very likely to be WONTFIX since the current plan like the rest
of the suite is to separate the apps.

Updating owner since mostafah is new head

Comment 16

[Steve Wardell]

I'm not so sure we should back off so easy on this. There is definitely a plan
for creating and furthering separate mail / news / etc applications however from
my understanding it has not been determined that the "suite" will cease to
exist, thou perhaps with less resources put into it by Mozilla.org. So this
perhaps could still be part of the suite. This was my understanding, thou I may
be incorrect.

Comment 17

[tae_kwang_do]

Any chance of this still happening?

Skipping why I think building Calendar by default would be good for Mozilla.

I am willing to help make this happen in what limited non-programmer ways I can.

Thanks.

Comment 18

[Robert Kaiser]

I have been building Mozilla with --enable-calendar for ages now, and I didn't
see any problems. I beleive it should be save to flip it on from this poijnt of
view...

Comment 19

[David G King]

From looking at my CVS pulled configure file, --enable-calendar is on by default.

Comment 20

[Robert Kaiser]

David, I'd wonder if it was on by default, the release and/or nightly builds
don't have it included...

Comment 21

[Roland Mainz]

Is there anything blocking this bug ?

Comment 22

[Robert Kaiser]

Roland:
I don't think so, building calendar works quite well for me, and I guess an
integrated calendar could attract a bunch of additional users to the Seamonkey
suite. The installer builds can and should have a checkbox to install or not
install it anyway.

Comment 23

[Justin Wood (:Callek)]

Mike P. 

Shouldn't this (as an overall tracking bug) have meta keyword?

Comment 24

[Aleksey Nogin]

Can --enable-calendar be made default now? Reassigning this to the gereral
Mozilla Build Config component for consideration.

Comment 25

[cls]

This is still not a build config issue.  It's a policy issue.  Drivers needs to
decide if they want this functionality on by default or not.  Last I heard (many
many moons ago), the code still hasn't been given a proper superreview though
we've been pulling it by default for a long while now.

Comment 26

[Asa Dotzler [:asa]]

Not a chance. We're certainly not going to enable a new feature (much less an
entirely new application) that wasn't shipped in alpha and beta. For something
as large as Calendar, it might not even make the final if it was enabled in
alpha. On top of that, there are review requirements and other considerations.
Definitely not a 1.7 blocker.

Comment 27

[Roland Mainz]

Note that the Solaris release builds ship with Calendar enabled since several
milestones without problems.

Comment 28

[Steve Wardell]

Could we target enabling immediately after the 1.8 trunk opens up perhaps for
all platforms?

Comment 29

[Brendan Eich [:brendan]]

I'm not going to fix this, but whoever wants calendar can mail drivers about it.
 Cc'ing shaver, who may have a better idea.

/be

Comment 30

[Brendan Eich [:brendan]]

Actually, I think chofmann will help champion this to the rest of drivers.

/be

Comment 31

[Aleksey Nogin]

Now that the 1.7 is branched, what needs to happen for calendar to become a part
of the default builds?

Comment 32

[timeless]

how about fixing the assertions that everyone seems to get and ignore?

Comment 33

[Roland Mainz]

Aleksey Nogin wrote:
> Now that the 1.7 is branched, what needs to happen for calendar to become a 
> part of the default builds?

Something like:
1. File a patch which turns the "--enable-calendar" switch into a
"--disable-calendar" switch and request review
2. Email [e-mail] with the module owner (mastafah?) in the CC: and
explain why this change would be a good idea etc. etc. :)

Comment 34

[timeless]

other items on my list, libical and libxpical still fail DRefTool (see
MozillaTest tinderbox)
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1081432200.8221.gz

there are two flavors of libical, the one from mozilla's cvs (which appears w/
bonsai links) e.g.:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/other-licenses/libical/src/test/stow.c&rev=1.2&mark=235#230
  Deref-error: "p"
and the one from libical's cvs (which doesn't have a bonsai link because
dreftool doesn't recognize its server):
/libical/src/libical/vcomponent.cpp   Deref-error: "thisProp"

afaik calendar was never sr'd, so someone really sure try to do something like
an sr.

Comment 35

[Aleksey Nogin]

Attachment: Add the calendar component to xpinstall/packager/packages-unix

Comment 36

[Aleksey Nogin]

Comment on attachment 146140 [details] [diff] [review]
Add the calendar component to xpinstall/packager/packages-unix

Am I missing any files here? Am I right that this (and similar changes to
package files on othe platforms) could (and probably should) be checked in
before the enable-calendar becomes the default?

P.S. I am hoping that somebody more familiar with Mozilla build system and
process would be driving the "build calendar by default" changes. I am doing
it, not because I feel qualified, but because I feel impatient ;-)

Comment 37

[Aleksey Nogin]

Attachment: Change --enable-calendar into --disable-calendar (making it enabled by default)

Comment 38

[Justin Wood (:Callek)]

as a side-note should be enable by default on all platforms yet, I would
personally like to see a few more use-ability stuff in, fixed and code sped up
before we *make* it shown to everyone, some stuff, especially on busier months
are very slow on my 2ghz (1gigRam) machine, WinXP Pro...

though still would love to see this default

wouldn't there need to be some changes to header files too for this, or am I
mistaken?

Comment 39

[Prognathous]

(In reply to Asa Dotzler, comment #26)
> We're certainly not going to enable a new feature (much less an
> entirely new application) that wasn't shipped in alpha and beta.

We're not out of beta with the 1.8 cycle, here is our chance to do the right
thing and put the Calendar through its QA paces.

Prog.

Comment 40

[Steve Wardell]

I'd like to highly encourage this as well. With the stable 1.7 long live
branched off, this would seem to be a good time.

While this of course is probably not a blocker per se, it is something that
would be wonderful to target for 1.8. If we can get the calendar in regular use,
there will probably be enough effort to get it in a state so that we could
position Moz as a more fully Outlook replacement. Calendaring is a critical
feature for some users.

Comment 41

[Asa Dotzler [:asa]]

and a pre-emptive blocking1.8beta- and blocking1.8-

Comment 42

[Justin Wood (:Callek)]

Comment on attachment 146155 [details] [diff] [review]
Change --enable-calendar into --disable-calendar (making it enabled by default)

I'm not okapi but

MOZ_ARG_ENABLE_BOOL( --disable...

seems very, backwards to me.

Should you not use MOZ_ARG_DISABLE_BOOL, and keep the =1 inside the def space.

see 
http://lxr.mozilla.org/mozilla/source/build/autoconf/altoptions.m4#46

For the area where it is defined.

Comment 43

[Steve Wardell]

Comment on attachment 146140 [details] [diff] [review]
Add the calendar component to xpinstall/packager/packages-unix

With Lightning coming up in near future hopefully, I'm pulling request on this.
If someone else wishes to follow-up though, please do.

Comment 44

[Josh Aas]

Comment on attachment 146155 [details] [diff] [review]
Change --enable-calendar into --disable-calendar (making it enabled by default)

cancelling reviews since it seems like this is a higher level decision that needs to be made, no point in reviewing this patch now

Comment 45

[Justin Wood (:Callek)]

overall this patch (for my intent) was targetted at Mozilla Suite, which should not (imo) get as big an addition as this, if it is the "Mozilla Suite", as for SeaMonkey, it would be a SeaMonkey Council decision if they want Calendar by default...  (as I understand it).

The patch also probably has bitrotted, and would still need a review anyway if it was to be decided 'we want this'.

Comment 46

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

AIUI, calendar isn't ready yet on 1.8.0 branch.  Not blocking 1.0.3.

Comment 47

[Worcester12345]

(In reply to comment #46)
> AIUI, calendar isn't ready yet on 1.8.0 branch.  Not blocking 1.0.3.
> 

Sorry, my bad. I meant 1.1.

Comment 48

[Robert Kaiser]

Calendar support for SeaMonkey has been dropped, --enable-calendar doesn't work anymore, so we can't even turn it on any more.

For future SeaMonkey versions (1.5 and above), we hope we can get the "Lightning" extension working to provide calendaring again.

Comment 49

[Worcester12345]

(In reply to comment #48)
...
> For future SeaMonkey versions (1.5 and above), we hope we can get the
> "Lightning" extension working to provide calendaring again.

Is there an existing bug for "Lightning" and calendar and "Seamonkey" (1.5 and above)?

Comment 50

[Matthew (lilmatt) Willis]

(In reply to comment #49)
> Is there an existing bug for "Lightning" and calendar and "Seamonkey" (1.5 and
> above)?

There isn't one in Calendar, but I'm not sure if one exists in SeaMonkey. You're welcome to use Bugzilla's search function to try and find one.

Please note that such a bug should live in SeaMonkey's Bugzilla, and not Calendar's. If a toolkit-based SeaMonkey wishes to work with Lightning, we're supportive, but the bulk of that work rests with the SeaMonkey team.

Comment 51

[Robert Kaiser]

(In reply to comment #49)
> Is there an existing bug for "Lightning" and calendar and "Seamonkey" (1.5 and
> above)?

See bug 313822, that should be the major step to get it working. Shipping it by default is a different opic though, which we will only address once that bug has been resolved.

Comment 54

[Worcester12345]

(In reply to comment #51)
> (In reply to comment #49)
> > Is there an existing bug for "Lightning" and calendar and "Seamonkey" (1.5 and
> > above)?
> 
> See bug 313822, that should be the major step to get it working. Shipping it
> by default is a different opic though, which we will only address once that
> bug has been resolved.

It has been resolved.