Closed Bug 182076 Opened 22 years ago Closed 18 years ago

Build with --enable-calendar by default.

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: mikeypotter, Assigned: chofmann)

References

Details

Attachments

(2 files)

Add the calendar component to xpinstall/packager/packages-unix
657 bytes, patch
Details | Diff | Splinter Review
Change --enable-calendar into --disable-calendar (making it enabled by default)
711 bytes, patch
Details | Diff | Splinter Review 
This bug is going to be used to track the integration of calendar into the
default 1.3 alpha builds.
Status: NEW → ASSIGNED
Depends on: 146310
OS: Linux → All
Hardware: PC → All
Mike, 1.3a closes one week from today. Is this still doable?
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! :) )
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. :)
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
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.
Depends on: 117682, 178798
Depends on: 183966
No longer depends on: 183966
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 ?
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.

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 ;-)
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)?
Summary: Integrate Calendar Into 1.3 Alpha Builds → Integrate Calendar Into Default Builds
*** Bug 138192 has been marked as a duplicate of this bug. ***
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 ?
what's the status here? any chance to get the switch flipped in 1.4 cycle still?
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...
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.
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
Assignee: mikep → mostafah
Status: ASSIGNED → NEW
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.
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.
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...
From looking at my CVS pulled configure file, --enable-calendar is on by default.
David, I'd wonder if it was on by default, the release and/or nightly builds
don't have it included...
Is there anything blocking this bug ?
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.
Mike P. 

Shouldn't this (as an overall tracking bug) have meta keyword?
Can --enable-calendar be made default now? Reassigning this to the gereral
Mozilla Build Config component for consideration.
Assignee: mostafah → nobody
Component: Calendar General → Build Config
Product: Calendar → Browser
QA Contact: brantgurganus2001 → core.build-config
Version: unspecified → Trunk
Flags: blocking1.7?
Summary: Integrate Calendar Into Default Builds → Build with --enable-calendar by default.
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.
Assignee: nobody → brendan
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.
Flags: blocking1.7? → blocking1.7-
Note that the Solaris release builds ship with Calendar enabled since several
milestones without problems.
Could we target enabling immediately after the 1.8 trunk opens up perhaps for
all platforms?
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
Assignee: brendan → nobody
Actually, I think chofmann will help champion this to the rest of drivers.

/be
Assignee: nobody → chofmann
Now that the 1.7 is branched, what needs to happen for calendar to become a part
of the default builds?
how about fixing the assertions that everyone seems to get and ignore?
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 drivers@mozilla.org with the module owner (mastafah?) in the CC: and
explain why this change would be a good idea etc. etc. :)
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 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 ;-)
Attachment #146140 - Attachment filename: mozilla-calendar.patch → mozilla-calendar-pack-unix.patch
Attachment #146140 - Flags: review?
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?
Flags: blocking1.8a?
Flags: blocking1.8a? → blocking1.8a-
(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.
Flags: blocking1.8a3?
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.
and a pre-emptive blocking1.8beta- and blocking1.8-
Flags: blocking1.8a3?
Flags: blocking1.8a3-
Flags: blocking1.7.2-
Attachment #146140 - Flags: superreview?
Attachment #146155 - Flags: superreview?
Attachment #146155 - Flags: review?
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.
Product: Browser → Seamonkey
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.
Attachment #146140 - Flags: superreview?
Attachment #146140 - Flags: review?
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
Attachment #146155 - Flags: superreview?
Attachment #146155 - Flags: review?
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'.
Flags: blocking-seamonkey1.0.3?
AIUI, calendar isn't ready yet on 1.8.0 branch.  Not blocking 1.0.3.
Flags: blocking-seamonkey1.0.3? → blocking-seamonkey1.0.3-
(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.
Flags: blocking-seamonkey1.1a?
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.
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: blocking-seamonkey1.1a? → blocking-seamonkey1.1a-
Resolution: --- → WONTFIX
(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)?

(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.
Status: RESOLVED → VERIFIED
(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.

(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.
QA Contact: build-config → build-config
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: