Re: Can I set build configurations in Swift code?
Re: Can I set build configurations in Swift code?
- Subject: Re: Can I set build configurations in Swift code?
- From: Britt Durbrow <email@hidden>
- Date: Mon, 07 Jul 2014 23:07:12 -0700
Hmm… might be a bit of a tangent, but I think it’s potentially relevant, since this is stuff that the C preprocessor handles: rdar://problem/17227308
Also, seeing this in light of what I got back from my bug report is a bit confusing… apparently there’s preprocessor functionality present in Swift that’s undocumented at the moment???
And for everybody else outside of Apple, here’s the relevant parts of the radar (umm… given that there’s nothing even remotely confidential in here, I guess that it’s OK to post):
I filed:
> Swift seems to have no mechanism that provides the functionality of the C preprocessor.
>
> I have a large amount of code that requires compile-time configuration for multiple targets (currently implemented with #define and #ifdef), as well as making extensive use of macros (including string concatenation and macros that are used for code annotations that other tools read which are #defined to nothing so that the compiler doesn't choke over them).
>
> I also have a large set of classes with auto-generated extensions (i.e, code files that were generated by one of my tools) that although it *could* be managed in Swift, doing so would require manual file management in Xcode - I currently have a few #include lines in my class template file that handles this automatically; although not needing headers in Swift is definitely a good thing, not having #include available from a preprocessor for other situations isn't.
>
> Note that this is all in modern Objective-C; something that Swift is supposed to interoperate with, but can't because of this lack of functionality.
And got back:
> Engineering has determined that this issue behaves as intended based on the following:
>
> We are not implementing a C-like token-based preprocessor. Compile-time configuration for multiple target is done using build configuration directives (please refer to documentation).
>
> Annotations that are have no runtime semantics can be achieved using, for example, identity generic functions:
>
> // define an annotation
> func annotateFoo<T>(x: T) { return T }
>
> // use it
> var x = annotateFoo(a + b) * c + d
>
> The code generation part is covered by other bug reports, for example: Bug ID 17200498.
>
> We are now closing this bug report.
>
> If you have questions regarding the resolution of this issue, please update your bug report with that information.
>
> Please be sure to regularly check new Apple releases for any updates that might affect this issue.
>
… which doesn’t really solve the problem. <sigh>
In Objective C, I’m doing something like this:
// in a header elsewhere:
#define Persistent
#define Accessor
#define End
#define StorageAlias(name)
// and in the class’s header:
@interface MyClass : RPCPersistent
{
StorageAlias(Line);
Persistent Accessor
RSHF64 startX;
RSHF64 startY;
RSHF64 endX;
RSHF64 endY;
End
someOtherClass *someOtherVarsHere;
}
// And this auto-generated file declares accessor properties for startX, startY, etc...
#import "MyClass.agh"
-(void)doSomething;
@end
The #defined words here are supposed to act as if they were language keywords, not functions, so var x = annotateFoo(a + b) * c + d; just doesn’t quite work right, IMHO. And in any case - I’d really rather that the underlying compiler not even see them (which is the way that the C preprocessor works).
Note that (as I stated above) if there is equivalent functionality in Swift, it seems to be undocumented at the moment - or at least, I couldn’t find it.
P.s. Given the line:
> The code generation part is covered by other bug reports, for example: Bug ID 17200498.
Shouldn’t this have been flagged as a duplicate, not just closed as "this issue behaves as intended”; such that the other bug report gets the proper weight that it deserves???
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden