Re: problem loading NSBundle in TalkSoup

[Richard Frith-Macdonald]

On 15 Mar 2015, at 11:19, Riccardo Mottola <riccardo.mottola@libero.it> wrote:
> 
> Hi,
> 
> Riccardo Mottola wrote:
>> 
>> It is thus somehow a build problem: GNUstep make tries to be smart, merges 
>> in some Mac stuff which confuses then the code at runtime.
> I have the "proof" by checking messages=yes:
> 
> echo "OLD_GNUSTEP_STAMP_ASTRING = _Ignore-" > ./Ignore.bundle/stamp.make
> (echo "{"; echo '  NOTE = "Automatically generated, do not edit!";'; \
>  echo "  NSExecutable = \"Ignore\";"; \
>  echo "  NSMainNibFile = \"\";"; \
>  echo "  NSPrincipalClass = \"Ignore\";"; \
>  echo "}") >Ignore.bundle/Resources/Info-gnustep.plist
> if [ -r "Ignore-Info.plist" ]; then \
>  plmerge Ignore.bundle/Resources/Info-gnustep.plist Ignore-Info.plist; \
> fi
> 

You appear to be building a bundle called 'Ignore' ... and the file gnustep 
uses to let you specify properties for the bundle 'Ignore' is called 
'Ignore-Info.plist'
It therefor generates the output file (Info-gnustep.plist) by merging values 
you specified in the makefile with the values in 'Ignore-Info.plist'

> Can I skip this plmerge step? Do I need to rename all the new *-Info.plist I 
> created in Xcode I hope not... that would be long tedious work.

If you mean them to be used by OSX and *not* by GNUstep, then you should rename 
them.  However, you might want the same info for both.

> Perhaps I can just fix in Xcode
> 
> CFBundleIdentifier = "org.gnustep.${PRODUCT_NAME:rfc1034identifier}";
> 
> to
> 
> CFBundleIdentifier = "org.gnustep.Ignore";
> 
> perhaps I even should add a level and add TalkSoup? 
> org.gnustep.TalkSoup.Ignore ?
> 
> That would be my last resource though, Id prefer to be able to tell gnustep 
> to skip XCode stuff if it is not needed or can't be shared.
> 
> Riccardo
> 

This *sounds* like an application level bug ... each bundle should have a 
*unique* identifier (or have no identifier).

You should not be creating multiple bundles with the same identifier in 
OSX/Cocoa any more than you should in GNUstep.  In both cases the identifer is 
supposed to identify the bundle, and while you may have seen that break 
something in GNUstep (and not seen the same problem in Cocoa), it probably just 
breaks things in a different way in Cocoa (for sure I'd expect the 
bundleWithIdentifier: method to produce bad results in Cocoa if you have 
created multiple bundles with the same identifier).

Here is what the main gnustep-make documentation (which answers your question 
about how the principal class is found and how plists are handled) for building 
bundles says:

# The name of the bundle is in the BUNDLE_NAME variable.
# The list of bundle resource file are in xxx_RESOURCE_FILES
# The list of localized bundle resource files is in
#                               xxx_LOCALIZED_RESOURCE_FILES
# The list of languages the bundle supports is in xxx_LANGUAGES
# The list of bundle resource directories are in xxx_RESOURCE_DIRS
# The name of the principal class is xxx_PRINCIPAL_CLASS
# The header files are in xxx_HEADER_FILES
# The directory where the header files are located is xxx_HEADER_FILES_DIR
# The directory where to install the header files inside the library
# installation directory is xxx_HEADER_FILES_INSTALL_DIR
# where xxx is the bundle name
#
# If you want to insert your own entries into Info.plist (or
# Info-gnustep.plist) you should create a xxxInfo.plist file (where
# xxx is the bundle name) and gnustep-make will automatically
# read it and merge it into Info-gnustep.plist.