Add the option to disable linking against the main crate #54
Conversation
This is mostly useful when your tests require building some piece of C code, but you do not want the entire crate to be linked against it. You can then just do `#[cfg_attr(test,link(name = "mylibrary", kind = "static"))]` and the code will only be linked for tests.
|
Sounds like a good idea to me, thanks! Could you also guard the print for I also think that |
Actually there's small convenience upside in keeping the println statement for the search path, but that might be trumped by consistency concerns (either you emit metadata for cargo or you don't), and it's not that difficult to get the reference to the
Yep, that's a good idea. |
|
Yeah these are basically all pure convenience (e.g. doing the prints for you) so I'd prefer to be consistent and not print any metadata if this option is specified, and as you mentioned you can always print the |
Agreed. That's what the updated PR does now. |
|
Thanks! |
Support for the GNUstep Objective-C runtime Restore accidentally lost attribute Cross-platform support for message sends with the GNUstep runtime. Add feature gates for the platform specific objc_msgSend implementation used by the GNUstep runtime (mips not currently supported because I'm unaware of the calling conventions). In all other cases, fall back to the cross-platform two-stage message sending. This now works and passes some of the tests (I had a buggy old gcc version yesterday, it seems). Every test that assumes NSObject to be present fails, though because that is not part of the GNUstep runtime. We'll either have to link gnustep-base for the tests to run properly, or provide stub implementation. Fix calling objc_slot_lookup_super(), which had the argument type wrong. Trick the linker into linking gnustep-base to pull in NSObject, eventhough we never reference the symbol for it. Also a bit of documentation. Fix libobjc2 repository location. Satisfy test dependencies using a stub NSObject implementation. Requires a patched gcc crate at the moment. Word Update to track proposed gcc-rs API Changes to the gcc crate were merged (cf. rust-lang/cc-rs#54) Experiment with travis builds Slim down a bit Shell script syntax is hard More shell script tweaks Tweak libobjc2 install location Stage libobjc2 into a local directory Conditionalize features, fix missing ‘;’ again. GNUstep base is no longer required for running tests. Fix gcc-rs revision Depend on a specific gcc-rs revision from github until a release includes the changes needed. Update dependencies to the released gcc-rs version. Exclude .travis.yml from publishing Restore original arch (aarch64 was incorrectly replaced with arm) Move NSObject dependency for tests with the GNUstep runtime into a sub-crate Rename ‘gnustep_runtime’ to ‘gnustep’ for brevity.
Hi,
I have a suggestion for an improvement: At the moment, the archives produced by a build script using gcc-rs are unconditionally linked to the crate that is being built. But there are certain use cases where that is not desirable, for example when you only want to link the built artifact for tests. This is presently only possible by dropping down to constructing the compiler command line manually, which is not really desirable for portability reasons.
So I propose adding a
link()option that you can add to the configuration in order to disable linking. The default would still betrue, of course. Please have a look and tell me what you think.Thanks,
Niels