<div dir="ltr"><div dir="ltr">On Wed, Jan 2, 2019 at 10:20 AM Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com">ben.boeckel@kitware.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Dec 31, 2018 at 15:30:28 -0800, Saleem Abdulrasool wrote:<br>
> AFAIK, the driver interface is supposed to be stable.  The frontend options<br>
> are not, but, the same holds true for clang as well.  The driver options<br>
> are stable, and we (as the clang developer community) aim to not break<br>
> that.  However, the frontend flags are entirely in the purview of the<br>
> compiler developers and those change as needed.<br>
<br>
OK, that's good to hear.<br>
<br>
> swiftc -c -primary-file <SOURCE> -o <OBJECT> -emit-module-path<br>
> <OBJECT>.swiftmodule -emit-module-doc-path <OBJECT>.swiftdoc<br>
> <TARGET_SOURCES><br>
> <br>
> This allows the compiler to look through the other sources which will be<br>
> part of the module and perform semantic analysis across them if/when<br>
> necessary.<br>
> <br>
> Adding per file properties would still be possible, and, IMO, desired.<br>
> That is part of the reason for doing the compilation in this mode rather<br>
> than a single pass over the complete file set.  That said, most of the<br>
> options really should be at a module level.<br>
<br>
Ah, I see. This is also news to me. I think adding `<TARGET_SOURCES>`<br>
would be suitable. However, it might need to be `<TARGET_SOURCES:Swift>`<br>
since I suspect `swiftc` won't take kindly to C++, C, or their headers<br>
files sneaking in on its commandline.<br></blockquote><div><br></div><div>Interesting idea.  I was thinking that for the initial implementation, we could make this harder to use instead.  Swift libraries should only be given swift sources.  You build your C sources (if any, this should/is fairly rare) as a separate object library and link it into the final link.  However, if filtering the sources is there, that would certainly be a nice feature.  I don't see any placeholders with this behaviour currently.  Any suggestions on how to best handle this?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> On Mon, Dec 31, 2018 at 2:17 PM Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>> wrote:<br>
> > Other questions which spring to mind:<br>
> ><br>
> >   - Does it support making just the compile artifacts from the source<br>
> >     files or does it always do the link step?<br>
> <br>
> The approach that I am taking does a separate compile and link step.  This<br>
> allows for a better behavior when it comes to incremental builds which I<br>
> care about.<br>
> <br>
> >   - If the latter, how do mixed language libraries work?<br>
> <br>
> The latter is what I believe most people have done, partially due to lack<br>
> of understanding of how the build model works with swift which is<br>
> completely understandable given that it is relatively opaque and it has not<br>
> been documented as thoroughly as C/C++.<br>
> <br>
> >   - Also, if linking is done by Swift, how would one add a manifest or<br>
> >     .rc file on Windows (e.g., to get an application icon)?<br>
> <br>
> Well, you would still want to link using the swift driver, not the linker<br>
> directly much like you use the driver to link C/C++.  I believe the changes<br>
> have also been back ported to the 5.0 release to pass options from the<br>
> [swift] driver to the [clang] driver to have them be translated<br>
> appropriately for the linker in use.  But, the manifest and resource file<br>
> handling is done by the linker IIRC, so this is largely unchanged beyond<br>
> the need to pass along the right flags.<br>
<br>
It sounds like `swiftc` is now much closer to the C++ separate TU<br>
compilation model that CMake kind of assumes now (or at least supports<br>
it). This should be fine then.<br>
<br>
> > The list of restrictions would need to be well-defined here first I<br>
> > think.<br>
> <br>
> I think that there aren't very many restrictions that come to mind.  The<br>
> biggest one is that it would be *extremely* helpful to have language<br>
> specific properties that can be set, but, I really was hoping that there<br>
> was a way to do this with a backwards compatible manner.  It would be<br>
> helpful to have a property to indicate things like the swift version and<br>
> the module name.<br>
<br>
Language-specific properties are fine for a new language. The only<br>
backwards compat I can think of is if people were using the<br>
now-important property names before, but I think that since doing<br>
`enable_language(Swift)` is an explicit action, developers can ensure<br>
that their conflicting property names are not an issue.<br>
<br>
> I'm happy to go into more detail, but, I'm really not sure I have an<br>
> understanding of what things you may be thinking of as restrictions here.<br>
<br>
I haven't thought too deeply on it either, but experience has shown that<br>
there are always corner cases. As long as the initial implementation is<br>
explicit about its use cases and errors on anything not tested, relaxing<br>
it for future use cases is easier than allowing everything and using<br>
policies to fix what is broken.<br></blockquote><div><br></div><div>Yeah, the corner cases always come out.  I think that having something that works is usually a good starting point to getting to the point where the corner cases can be considered.  I think that we are in agreement that being stringent and relaxing is easier than being accepting and then tightening the requirements later.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
<br>
--Ben<br>
</blockquote></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div></div>