Lightning is using some binary components (libical and some backend cpp files. Binary components were discontinued so starting with TB 52 they were linked into libxul. Bug 1318258 covers this. SeaMonkey releases are currently build without calendar because we still have not solved the l10n repack bug 1231349. The consequence is that the binary components are not build and the current Lightning on AMO does not work or better is completly broken. You will see various failues in the preferences and processing. The same would occur if you build TB without calendar. The solution would be to always build the binary components for later use.

Patch for 2.49.1 SeaMonkey comm-esr52 relbranch only. Verified working on Linux and Windows x64. Workaround only. Can not be used in a normal production branch because this would break building Lightning.

Fallen, I assume the binary components are here to stay. Shouldn't the calendar tree be refactored in light of this? If you think yes I can try to fix this properly. Maybe Lightning should be dropped as an add-on and always be build into both TB and SM? The current setup will probably completly break in the near future with the current Gecko api removals and changes.

ewong configure output error with the jars still in the tree.

Comment on attachment 8911790 [details] configurerrror.txt And this is with the following change only? -if CONFIG['MOZ_CALENDAR']: - DIRS += [ +DIRS += [ '/calendar/lightning', - '/calendar/timezones' - ] +] What about just: diff --git a/suite/app.mozbuild b/suite/app.mozbuild --- a/suite/app.mozbuild +++ b/suite/app.mozbuild @@ -10,18 +10,13 @@ include('/toolkit/toolkit.mozbuild') if CONFIG['MOZ_EXTENSIONS']: DIRS += ['/extensions'] if CONFIG['MOZ_COMPOSER']: DIRS += ['/editor/ui'] DIRS += ['/%s' % CONFIG['MOZ_BRANDING_DIRECTORY']] -if CONFIG['MOZ_CALENDAR']: - DIRS += [ - '/calendar/lightning', - '/calendar/timezones' - ] DIRS += [ '/xpfe/components/autocomplete', '/suite', ]

Comment on attachment 8911512 [details] [diff] [review] 1402645-249-relbranch.patch I am not 100% sure the need to do a wholesale removal of those files. As mentioned in comment #4, with the removal of the if CONFIG['CALENDAR']: part of app.mozbuild, I believe it is sufficient to disable calendar.

Added back some parts which I think are safe, did a fresh compile and retested it. Some other parts could, for sure, be added back to the moz.build files too but every full compile with at least two languages is a 40 minutes round trip + test and so I just consider it working fine for now unless the real build breaks :) Happy to test other patches if needed. As before only for the SeaMonkey relbranch in comm-esr52 and needs to be backed out when we are finally solve the l10n bug.

Comment on attachment 8912293 [details] [diff] [review] 1402645-249-relbranch-V2.patch Well, it builds..

Comment on attachment 8912293 [details] [diff] [review] 1402645-249-relbranch-V2.patch If you are removing the JAR_MANIFESTS += ['jar.mn'] lines from the moz.build files, do you actually need to remove the jar.mn files? r/a=me for comm-esr52

> do you actually need to remove the jar.mn files? Unfortunately yes see attachment in comment 3.

SEAMONKEY_2_49_ESR_RELBRANCH only: https://hg.mozilla.org/releases/comm-esr52/rev/684e4c349de07eb06ac08120fbfdc74d6b42d29b Leaving the bug open for finding a permanent solution.

(In reply to Frank-Rainer Grahl (:frg) from comment #2) > Fallen, > > I assume the binary components are here to stay. Shouldn't the calendar tree > be refactored in light of this? If you think yes I can try to fix this > properly. I don't see myself finding any time to work on the ical.js port soon, so even though it is just a hack what we currently do, it is indeed here to stay. Refactoring the source files for the binary component into a separate directory would substantially rip out files that are only really useful for Lightning. I think I'd prefer to keep them in place, but you can of course add the specific directory with binary files for compiling in even without enable-calendar. > > Maybe Lightning should be dropped as an add-on and always be build into both > TB and SM? The current setup will probably completly break in the near > future with the current Gecko api removals and changes. Until the add-on APIs break I think this is not necessary.