discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reorganization of Info.plist


From: David Ayers
Subject: Re: Reorganization of Info.plist
Date: Fri, 30 Apr 2004 11:05:55 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

Nicola Pero wrote:

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.


It's not clear to me what happens if an xxxInfo.plist exists. Does an xxx_Info.plist get generated anyway? If it does, does it "plmerge" the contents of the xxxInfo.plist into the xxx_Info.plist? Will xxxInfo.plist be ignored of both xxxInfo.plist and xxx_Info.plist exist?

From my POV it would be fine that the xxx_Info.plist doesn't get created (nor "plmerged" from the xxxInfo.plist) if an xxxInfo.plist exists. Yet it could simply emit a warning that xxxInfo.plist is deprecated.

Also would -make do any "consistency checking" that the xxx_Info.plist contains some minimal information? I don't think it's really necessary, It should just be clear that it's up to the developer to provide a sensible xxx_Info.plist, if he provides anything, and can't rely on -make to fill any holes, which seems to be the intent.

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.

==

I'm not sure what that information was used for (IIRC this is a gnustep only feature for querying the Classes of a framework before loading it?) I guess it's up to the "users" of this feature to comment on that, as they would need to be aware of this change and adapt to it.

In general, I think removing this kind of complexity from -make is very good!

Cheers,
David




reply via email to

[Prev in Thread] Current Thread [Next in Thread]