bugGNUstep - Bugs: bug #29634, GNUSTEP_SHARED_BUNDLE_INSTALL_PATH...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #29634: GNUSTEP_SHARED_BUNDLE_INSTALL_PATH et al use GNUSTEP_INSTANCE instead of LIBRARY_NAME_WITHOUT_LIB

Submitted by:  Jamison Hope <jhope>
Submitted on:  Wed 21 Apr 2010 09:41:35 PM UTC  
 
Category: MakefilesSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

Thu 22 Apr 2010 09:10:27 AM UTC, comment #2:

Ok ... done.

Please check gnustep-make from trunk if you want to test this :-)

The fix will be included in gnustep-make 2.4.0, which is bound to be released in the next month or so.

Thanks

Nicola Pero <nico>
Project Member
Thu 22 Apr 2010 08:45:48 AM UTC, comment #1:

Well done Jamison!

Not only this is the right place to report the bug, but your fix looks spot on :-)

Great stuff. A few comments -

  • in newer versions of gnustep-make, we're trying to allow people to use LIBRARY_NAME=Foo and LIBRARY_NAME=libFoo interchangeably. It shouldn't matter which of the two they use; the result should be the same. (one reason is to support native-library.make, another reason is that people often simply forget about adding 'lib' at the beginning and we want to make life easy for people). For this reason alone, using GNUSTEP_INSTANCE in GNUSTEP_SHARED_BUNDLE_INSTALL_PATH is definitely wrong; GNUSTEP_INSTANCE might or might not contain 'lib'. We should either use LIBRARY_NAME_WITH_LIB or LIBRARY_NAME_WITHOUT_LIB instead, so the behaviour is consistent and clearly specified. :-)
  • depending on whether we replace GNUSTEP_INSTANCE with LIBRARY_NAME_WITH_LIB or LIBRARY_NAME_WITHOUT_LIB, we'll (potentially) break some existing makefiles. Unfortunately, there's nothing we can do about that.
  • I'm pretty sure we actually want to use LIBRARY_NAME_WITHOUT_LIB as you suggest. For a number of reasons:

1. the "documentation" (aka comments inside Instance/library.make) mention

GNUSTEP_LIBRARY/Libraries/gnustep-base/Versions/1.14/Resources/

so I guess that is the documented, expected behaviour. :-)

2. frameworks put resources into directories without "lib" and it's good to be consistent with frameworks

3. most users who use library resources managed by gnustep-make are using native-library.make, a wrapper around library.make (or framework.make) which will generally be used without 'lib'. If we use LIBRARY_NAME_WITHOUT_LIB, we won't break these makefiles.

4. gnustep-base, gnustep-gui and others does use library resources and have 'lib' in the LIBRARY_NAME, but uses resource-set.make to install them. And again, they install into a directory without 'lib', so if we ever eventually want to move these to use library.make directly and the resource support available there, we want library.make to create the directory without 'lib'.

So, I'll apply your fix. I'll also update the gnustep-make release notes to explain that some makefiles might potentially be broken by the fix, if they were relying on library resources being installed into a directory with 'lib' in the name. People with this problem who need to support older versions of gnustep-make may need to remove 'lib' from their LIBRARY_NAME.

Thanks

Nicola Pero <nico>
Project Member
Wed 21 Apr 2010 09:41:35 PM UTC, original submission:

Instances/library.make defines GNUSTEP_SHARED_BUNDLE_INSTALL_PATH like this:

GNUSTEP_SHARED_BUNDLE_INSTALL_PATH = $(GNUSTEP_LIBRARY)/Libraries/$(GNUSTEP_INSTANCE)/Versions/$(INTERFACE_VERSION)

But GNUSTEP_INSTANCE is taken from LIBRARY_NAME, which the documentation says is supposed to include the "lib" prefix. This means that GNUSTEP_SHARED_BUNDLE_INSTALL_PATH ends up being something like "/usr/local/lib/GNUstep/Libraries/libFoo/Versions/0" instead of the correct "/usr/local/lib/GNUstep/Libraries/Foo/Versions/0".

If I follow the library.make documentation and use "LIBRARY_NAME=libFoo", then in my source code I have to call NSBundle with bundleForLibrary:@"liblibFoo", because NSBundle (correctly) removes a "lib" prefix before looking for the directory in the file system. The other option is to define LIBRARY_NAME=Foo despite the Make documentation, and then update the names of xxx_C_FILES and the other variables.

I think that the fix is just to use $(LIBRARY_NAME_WITHOUT_LIB) instead of $(GNUSTEP_INSTANCE) in the definitions of the GNUSTEP_SHARED_BUNDLE_* variables, but I do not understand the GNUstep make system fully enough to state that with 100% certainty. Regardless, I am attaching a diff against version 2.0.8 (taken from Ubuntu karmic) which performs that substitution.

Also: I hope this is still the right place to submit bug reports; I don't see any mention of an alternative at Gna!.

Jamison Hope <jhope>

 

Attached Files
file #20297:  library.make.diff added by jhope (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by nico (Posted a comment)
  • -unavailable- added by jhope (Submitted the item)
  • -unavailable- added by jhope
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 22 Apr 2010 09:10:27 AM UTCnicoStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Wed 21 Apr 2010 09:41:35 PM UTCjhopeAttached File-=>Added library.make.diff, #20297
      Carbon-Copy-=>Added nico

    Back to the top


    Powered by Savane 3.1-cleanup1