Fix loading of the Foundation framework under GNUstep #122
Conversation
There was a problem hiding this comment.
Pacth makes sense.
Given that most of the developer and user base is (currently) on Apple platforms, it would seem important that we have a mechanism to regularly test this branch of the code. If we're going to add this, I'd rather not add it and then have it immediately break because we add some feature that works differently on GNUstep.
Would it be possible to add a Unix build target to Travis as well?
This way a style error won't cause all environments to fail anymore.
|
Done. I've also taken the opportunity to move the |
Otherwise we can't build the test harness, due to missing headers.
The language doesn't need to be specified explicitly, the compiler can infer it from the source file extensions. There's no need to add tests/objc to the include path manually, since the source files are already in the same directory as the headers.
|
OK, for some reason The Linux tests are also failing because #114 isn't merged yet. |
freakboy3742
force-pushed
the
fix_gnustep_foundation
branch
4 times, most recently
from
42d1a61 to
c62e348
Compare
freakboy3742
force-pushed
the
fix_gnustep_foundation
branch
from
3a4d56d to
a8b64f3
Compare
|
Ok; I've been wrestling with this all morning, and I have reached the limit of my patience :-) I've worked out how to locate the GNUstep headers; but then blocks don't compile. You can add Making matters worse, Travis has been extremely flaky all morning, taking 10-15 minutes to spool up a Linux box, locking up during builds, timeouts during builds, failures due to random network and permissions errors. On top of that, there appears to be no documentation for the Xenial base image, which is required to get Python 3.7 working on Ubuntu. I'd love for Rubicon to support GNUStep; but at this point, I think we need someone who understands how GNUstep works to step up and fix the problems we're seeing. |
|
I've noticed that you switched the compiler to
This might be related to the GCC vs. Clang thing... I saw that GNUstep has the repo https://github.com/gnustep/libobjc2 on GitHub, whose description says "Objective-C runtime library intended for use with Clang". This appears to be a different library than the one installed by default with GNUstep (libobjc4). So maybe the default GNUstep install provides a runtime library that works only with GCC and not Clang, and if you want to use Clang you need to install a different runtime library? I have no idea really, maybe I'm jumping to conclusions here.
Agreed, that would be very helpful - I don't use Linux a lot, and have no experience with GNUstep aside from attempting to get Rubicon to work with it, so I keep running into issues that are probably quite obvious to someone used to developing on Linux. |
|
@dgelessus I switched to clang because gcc didn't seem to work - the issue appears to be Objective C syntax that doesn't appear to be supported on GCC. I could be completely wrong on that front, though - again, GNUstep's documentation is it's own worst enemy on this front. This points at the biggest concern I have with this patch. In theory, I'd love to be able to support GNUstep. However, given the state of GNUstep's documentation, I have absolutely no confidence that we (as in, you and I, as the primary maintainers) would be able to maintain GNUstep support once it was added. I don't want to be in a situation where progress on Rubicon that is needed for iOS/macOS support is being constrained because GNUstep's documentation allow us to work out how to support a new feature. |
|
This PR has undergone significant bitrot, and I don't have any personal motivation to continue trying to maintain it. I've opened #176 to track the feature request; if someone is sufficiently motivated, they can re-start this porting effort. |
Fixes #113.