The test should be done similarly, though: test for the feature rather than the compiler.
On Tue, Jun 27, 2017 at 9:15 PM, Fred Kiefer <fredkie...@gmx.de> wrote: > I agree that we should add this feature, but from looking at the actual code > I don’t think it will help us. > The feature seems to be only present in gcc on Darwin with the Next, that is > old Apple ObjC, runtime. We should rather be looking for a way to convince > the gcc people to enable this on more platforms. > This shouldn’t be much of a limitation for Daniel as he will be using clang > anyway. > > Fred > > >> Am 27.06.2017 um 19:34 schrieb Ivan Vučica <i...@vucica.net>: >> >> It seems sane, and you should update corebase's autoconf to detect presence >> of this compiler built-in. >> >> That is: an installed header should be generated and contain a constant >> describing whether CFStringMake...() is present. >> >> On June 27, 2017 5:32:04 PM GMT+01:00, "Daniel Ferreira (theiostream)" >> <bnm...@gmail.com> wrote: >> Hi, >> >> I'm currently working on developing a CoreFoundation-based library >> with CoreBase, and I just realized that unlike in OSX, CFSTR() does >> not generate a compile-time CFStringRef constant. >> >> This is fine compatibility-wise since CFSTR() does not guarantee that >> it will do so -- in fact, Apple's own CoreFoundation headers check if >> we are on Linux and if that is the case, it does not enable this >> compile-time feature. >> >> However, as far as my (extremely brief) investigation went we can >> generate compile-time CFStringRefs using >> __builtin___CFStringMakeConstantString(), which is present since this >> gcc commit[1] and since forever in clang. So it makes sense to me that >> this should not be platform-dependent, but rather compiler-dependent. >> >> This helps because I need to export some CFStringRefs as symbols in a >> new lib for WebKit compatibility, and without this feature I'd be left >> with the option to either: >> a) create an Objective-C file in a C-only library just for exporting >> NSStrings; >> b) make a bizarre __attribute__((constructor))-like thing to >> initialize the constant strings onto the symbols on library load. >> >> Does this seem sane? If so, I need a tip in how to guard for this >> builtin in gcc. >> >> -- Daniel. >> >> [1]: >> https://github.com/gcc-mirror/gcc/commit/d4238e8bcce578381de9480d78a651830a8f9754, >> looks like it was added in gcc 5.3. >> >> >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnustep-dev >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev