Reorganization of Info.plist

[Nicola Pero]

Hi

looking at some problems we have with the current way of generating
Info.plist files, I'd like to consider a pretty radical change in the way
our makefiles deal with those files.

Consider an application.

At the moment, you have a GNUmakefile which contains lines such as 

  Nicola_MAIN_MODEL_FILE = Nicola.gorm
  Nicola_APPLICATION_ICON = HappyProgram.png
  Nicola_PRINCIPAL_CLASS = MainController
  
and if you want to set more stuff in your Info.plist, you add a
xxxInfo.plist file.

gnustep-make will read your GNUmakefile variables, generate an Info.plist
fragment using those variables, then run plmerge to merge your
xxxInfo.plist file into that one.


Now if you think about it, this is pretty stupid. :-)

The process is complex, and it's generating something which ... is always
the same!  So why generating it?  The process is not even adding much
value, because for a programmer, writing

{
  NSExecutable = Nicola;
  NSMainNibFile = Nicola.gorm;
  NSIcon = HappyProgram.png;
  NSPrincipalClass = MainController;
}

is more or less the same amount of work than writing the equivalent lines
in the GNUmakefile, but it's more transparent, as what you write is what
you get.


So I'd like to change gnustep-make so that if you provide a file called
xxx_Info.plist (please note the underscore to differentiate it from the
xxxInfo.plist which is used at the moment), it will skip the process
entirely and just use that.  We'll have a makefile variable which lets you
change the name of the file used.

If there is no xxx_Info.plist, the file would be generated from the
GNUmakefile as it happens now.


The idea being that you have backwards compatibility, but that new
software would be developed in a different way: -- initially the
programmer just write his simple GNUmakefile, and when he does a make, a
minimal xxx_Info.plist is generated (something like {NSExecutable =
Program;}).  If he wants to set the principal class or add an icon or a
nib file, he'd add the variables directly into the xxx_Info.plist.  If he
wants to add any other custom variable to the Info.plist, he just adds it
directly.  gnustep-make will just copy his Info.plist into the application
directory and that's it.

This would be a lot more efficient in terms of building time, and a lot
simpler, as the programmer just edits his xxx_Info.plist, and what he
writes is what he gets :-)

==

Bundles, palettes and services can work in the same way.

Frameworks are a bit more tricky because they now include the list of
classes in the Info.plist.  That is a great feature, and we want to keep
it, but maybe that list of classes could go into a separate .plist ?  
Then we avoid the problem of merging the plists.

==

Comments are welcome.