Hi,
Sorry for the delayed response - I was at a workshop last week and was a bit
behind on email.
On 13 May 2018, at 22:08, Ivan Vučica wrote:
>
> Hi,
>
> to confirm, is current libobjc2 master incompatible with current gnustep-base
> master?
>
> Stjepan has been building GNUstep using the following instructions:
> http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux
> and I remembered that the failure could be due to the development of the new
> abi.
This is a bug in libobjc2, which I have now fixed. I forgot that objc_slot was
part of the public API and so renamed it to objc_slot_v1, which then broke
things. I have now reverted its name to objc_slot and introduced a new
objc_slot2, which fixes the issue.
> I powered on the laptop during my vacation, took a quick look, and told him
> to git checkout 1.9. This seems to have worked.
>
> Is this intentional?
No, it was a bug (though the master branch of libobjc2 may contain experimental
code so may be less reliable than a release).
On a related note, I have had no feedback at all from requests to test the 1.9
and master branches in preparation for the 1.9 and 2.0 releases.
> Presumably -base newabi branch is not ready to be merged yet — but should
> libobjc2’s master branch be using the new abi then?
I have some other changes in the -base newabi branch. It’s probably fine to
merge the changes so support the support for the new NSConstantString parts,
but unfortunately the new constant string exposes some bugs in -base’s unicode
handling (in particular, incompatibilities with NSString and GSString), which
are probably exposed by other NSString subclasses.
> I think that’s fine, apart from breaking scripts that build GS from head.
> Travis CI is also erroring out:
> https://travis-ci.org/gnustep/libs-base
The -base Travis script should be building libobjc2 without tests. The
libobjc2 Travis script builds it with tests and runs them.
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
