switch from .xulapp to application.ini bsmedberg and i discussed moving from name.xulapp to a generic application.ini. it seems like a good idea for a number of reasons: (1) no need to do file association with this file (installers should create symlinks, shell scripts, etc.) (2) nice to be able to have a known filename in each XUL app instead of having to guess the name based on application name or based on looking for files ending with the extension .xulapp. We also want to tweak our build system so that application.ini will be passed through preprocessor.pl before being copied into the application staging directory (dist/xpi-stage/$appname).

>(1) no need to do file association with this file (installers should create >symlinks, shell scripts, etc.) but you'd also lose the ability to double-click the file, right?

> but you'd also lose the ability to double-click the file, right? right, we figured that that just isn't very useful.

To be more precise, it isn't nearly as useful as associated the XULRunner with packed (zipped) myapplication.xulapp files, which will then be unpacked/installed.

> To be more precise, it isn't nearly as useful as associated the XULRunner with > packed (zipped) myapplication.xulapp files, which will then be unpacked/installed. But, that's a poor argument since we could have two distinct file extensions: one for the packaged extension and one for the INI file that is passed on the command line to xulrunner.

it seems to me that we should not only support launching applications via the start menu. being able to just copy the application directory to another computer seems useful (of course this will still only work if xulrunner is installed...)

I am not wedded to the "ini" extension... a more unique extension like .xini or .xinfo or .xapp would be fine with me. The important parts of my proposal are: 1) every application ought to have the same filename simple/application.xini hexminesweeper/application.xini jar:hexminesweeper.xpi!/application.xini 2) .xulapp should be the extension for a packaged application that should be installed

Let's stick with application.ini for now as there are some benefits to giving the file an extension that corresponds to its actual type ;-) There are tools out there such as MSI that know how to modify INI files, so it might be useful to have it named accordingly. I can't really think of any such cases off the top of my head, but without anything compelling me in another direction, I'm happy to just stick with application.ini.

This patch includes changes to rules.mk to simplify building XUL apps within the tree. If it sees the variable XULAPP defined, then it proceeds to attempt to preprocess application.ini and copy over chrome.manifest. I also fixed up the handling of PREF_JS_EXPORTS to properly install prefs into defaults/preferences instead of defaults/pref when XPI_NAME is defined. That makes sense for extensions as well as for XULRunner-based apps. To prove that this is a nice solution, I went ahead and converted layout debugger as well as the XULRunner simple example to use the new build fu. I think the result is pretty decent.

Comment on attachment 177683 [details] [diff] [review] v1 patch >+# Special handling for XULRunner-based applications >+ifeq ($(XULAPP),1) ifdef XULAPP but I don't like hardcoding these two files anyway. Why can't we add a generic makefile var: DIST_FILES = application.ini chrome.manifest extension.rdf install.js ... And preprocess these generically. Then add the -DBUILD_ID and whatever else to the individual makefile DEFINES. The gecko_version_major/minor stuff looks like good fodder for config.mk.

> DIST_FILES = application.ini chrome.manifest extension.rdf install.js ... Ok, interesting idea. How would rules.mk know that application.ini belongs in FINAL_TARGET and chrome.manifest belongs in FINAL_TARGET/chrome? Should rules.mk check the name of each file to determine this? BTW, in these examples we're really only talking about chrome.manifest, which was going to go away anyways, right? I'm using XULAPP=1 to specify that application.ini should be installed into FINAL_TARGET... are you objecting to that as well? > And preprocess these generically. Then add the -DBUILD_ID and whatever else to > the individual makefile DEFINES. The gecko_version_major/minor stuff looks > like good fodder for config.mk. BUILD_ID seems like a fairly standard thing to add to config.mk as well, don't you think?

(In reply to comment #10) > Ok, interesting idea. How would rules.mk know that application.ini belongs in > FINAL_TARGET and chrome.manifest belongs in FINAL_TARGET/chrome? Should > rules.mk check the name of each file to determine this? Hrm, does chrome.manifest belong in {app}/chrome/ ? In extensions it goes in the root directory {extension}/chrome.manifest. Sounds like a mismatch we ought to fix. What do you think of just having {app}/chrome.manifest instead of {app}/chrome/*.manifest ? > was going to go away anyways, right? I'm using XULAPP=1 to specify that > application.ini should be installed into FINAL_TARGET... are you objecting to > that as well? Well, I want to give the build system flexibility such that you can ship an application.ini, install.rdf, and install.js using the same basic rule. > BUILD_ID seems like a fairly standard thing to add to config.mk as well, don't > you think? Sure.

I have something like this in my tree right now, which I use to package a chrome.manifest from calendar/lightning. I'm very motivated to get _some_ such mechanism in the tree, so that I can check my changes in.

yikes.. i already have something in my tree too.. i'll take a look at your approach asap.

shaver: so for XUL apps, I was not defining XPI_PKGNAME. as a result, your patch wouldn't really address this problem. but, your problem could be solved by the DIST_FILES makefile variable that bsmedberg proposed and which I have implemented in my tree.

Yeah, I'm not religiously attached to that approach, or indeed to the XPI_PKGNAME stuff at all -- being able to share infrastructure with XULRunner apps would be a major win. I checked in a tiny interim patch so that I could make Lightning use chrome.manifest, but I stand ready to convert to a more righteous system, such as the DIST_FILES stuff.

shaver: it'd be great if you could take a look at this patch too.

Comment on attachment 178636 [details] [diff] [review] v2 patch Can we have the milestone.pl thing spit out separate major and minor versions, such that we can concatenate them to the MOZILLA_VERSION, rather than splitting them? Is XPI_NAME the right name? I'm not emotionally attached to it, and it seems like we almost want a broader name that covers both "extension" and "standalone XULRunner app" -- maybe XPI is good, just want to make sure my snap naming before doesn't constrain us overly. Patch looks pretty good; I'll try to convert Lightning to use such a patch to make sure it all works for that case, when I get a chance.

> Can we have the milestone.pl thing spit out separate major and minor versions, > such that we can concatenate them to the MOZILLA_VERSION, rather than > splitting them? Yeah, that's an option. But, this is done, and I'm not sure there is that much benefit to changing the way these things are generated. > Is XPI_NAME the right name? Yeah, I'm not sure I like XPI_NAME and dist/xpi-stage, but bsmedberg did try to convince me once that XUL apps probably should just be thought of as XPIs. They are XPIs without install.rdf or install.js :-) The idea here is that XUL apps will be delivered as zipped up packages that are installed by XULRunner onto the system. We may end up choosing a different file extension for distribution over the web, or we might even stick with XPI. I'm not sure yet. So, for now... XPI_NAME is fine.

The v2 patch was missing changes to toolkit/xre.

dang it.. and the v2.1 patch was missing newly added files. (sorry for the spam)

Comment on attachment 178672 [details] [diff] [review] v2.2 patch Please explain why the "changequote" directives are required.

changequote is needed because my regular expressions contain '[' and ']' characters, which are the default quoting characters for configure.in when m4 is run.

fixed-on-trunk

so... why the -DBUILD_ID, can't code just #include "nsBuildID.h" and use that?

(In reply to comment #25) > so... why the -DBUILD_ID, can't code just #include "nsBuildID.h" and use that? because we wanted it to apply to application.ini and various other preprocessed files. is there a reason why -DBUILD_ID is bad?

(In reply to comment #26) > is there a reason why -DBUILD_ID is bad? Nah, it just felt redundant to me...

W.r.t. these last few comments, also see bug 293455.