Closed Bug 440022 Opened 16 years ago Closed 16 years ago
ensure that Lightning doesn't have empty min/max
Version in install .rdf
When trying to build Lightning with mozilla-central, I noticed that its install.rdf ends up with <em:minVersion> and <em:maxVersion> tags for the product that I was not building at the moment, as we don't have the central configure define all the _VERSION variables any more. The real problem with that is that EM does not activate Lighting and always tells us it requires a restart to activate (but doesn't actually activate it with that restart) when it encounters such an empty version field for any application listed in the install.rdf (even when it's not the one we are installed in). Everything works fine though if the [min|max]Version tags are missing completely, so I figured we only should put them in there when the relevant _VERSION is defined, just to be on the safe side.
This patch makes us only use the _VERSION vars if they are set. The case when SEAMONKEY_VERSION is missing (normal Thunderbird build under Gecko 1.9.1) is pretty easy, the case when THUNDERBIRD_VERSION is missing (normal SeaMonkey build under 1.9.1) has been tested well by me and was the cause why I even came across this bug. I think it's worth taking this fix even if we might decide to define those variables for the default builds so that the install.rdf ends up being complete usually. This fix makes us create an install.rdf that at least works with one application when we somehow lose the version definition for the other (as it's currently the case in my setup described in the http://wiki.mozilla.org/SeaMonkey:hg-based_build wiki doc).
Assignee: nobody → kairo
Status: NEW → ASSIGNED
Attachment #325575 - Flags: review?(daniel.boelzle)
Attachment #325575 - Flags: review?(daniel.boelzle) → review?(ause)
Summary: make Lightning still work when not all _VERSION vars are defined during build → ensure that Lightning doesn't have empty min/maxVersion in install.rdf
After discussion with Standard8, this patch is more sane. We're now fetching those version values ourselves (in cvs, we always pull the version.txt files from other projects with client.mk, in the new repo, we always pull all Thunderbird and SeaMonkey files, so those always succeed) and completely lose the dependency on the build system providing any of those version numbers. The Firefox one will probably only work in the new repository, but I figured as long as we have that build option for install.rdf, we should support it in Makefile.in as well.
Checked into 1.8 branch and cvs trunk.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.9
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.