On Wed, Jan 2, 2019 at 10:20 AM Ben Boeckel <ben.boec...@kitware.com> wrote:
> On Mon, Dec 31, 2018 at 15:30:28 -0800, Saleem Abdulrasool wrote: > > AFAIK, the driver interface is supposed to be stable. The frontend > options > > are not, but, the same holds true for clang as well. The driver options > > are stable, and we (as the clang developer community) aim to not break > > that. However, the frontend flags are entirely in the purview of the > > compiler developers and those change as needed. > > OK, that's good to hear. > > > swiftc -c -primary-file <SOURCE> -o <OBJECT> -emit-module-path > > <OBJECT>.swiftmodule -emit-module-doc-path <OBJECT>.swiftdoc > > <TARGET_SOURCES> > > > > This allows the compiler to look through the other sources which will be > > part of the module and perform semantic analysis across them if/when > > necessary. > > > > Adding per file properties would still be possible, and, IMO, desired. > > That is part of the reason for doing the compilation in this mode rather > > than a single pass over the complete file set. That said, most of the > > options really should be at a module level. > > Ah, I see. This is also news to me. I think adding `<TARGET_SOURCES>` > would be suitable. However, it might need to be `<TARGET_SOURCES:Swift>` > since I suspect `swiftc` won't take kindly to C++, C, or their headers > files sneaking in on its commandline. > 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? > > On Mon, Dec 31, 2018 at 2:17 PM Ben Boeckel <ben.boec...@kitware.com> > wrote: > > > Other questions which spring to mind: > > > > > > - Does it support making just the compile artifacts from the source > > > files or does it always do the link step? > > > > The approach that I am taking does a separate compile and link step. > This > > allows for a better behavior when it comes to incremental builds which I > > care about. > > > > > - If the latter, how do mixed language libraries work? > > > > The latter is what I believe most people have done, partially due to lack > > of understanding of how the build model works with swift which is > > completely understandable given that it is relatively opaque and it has > not > > been documented as thoroughly as C/C++. > > > > > - Also, if linking is done by Swift, how would one add a manifest or > > > .rc file on Windows (e.g., to get an application icon)? > > > > Well, you would still want to link using the swift driver, not the linker > > directly much like you use the driver to link C/C++. I believe the > changes > > have also been back ported to the 5.0 release to pass options from the > > [swift] driver to the [clang] driver to have them be translated > > appropriately for the linker in use. But, the manifest and resource file > > handling is done by the linker IIRC, so this is largely unchanged beyond > > the need to pass along the right flags. > > It sounds like `swiftc` is now much closer to the C++ separate TU > compilation model that CMake kind of assumes now (or at least supports > it). This should be fine then. > > > > The list of restrictions would need to be well-defined here first I > > > think. > > > > I think that there aren't very many restrictions that come to mind. The > > biggest one is that it would be *extremely* helpful to have language > > specific properties that can be set, but, I really was hoping that there > > was a way to do this with a backwards compatible manner. It would be > > helpful to have a property to indicate things like the swift version and > > the module name. > > Language-specific properties are fine for a new language. The only > backwards compat I can think of is if people were using the > now-important property names before, but I think that since doing > `enable_language(Swift)` is an explicit action, developers can ensure > that their conflicting property names are not an issue. > > > I'm happy to go into more detail, but, I'm really not sure I have an > > understanding of what things you may be thinking of as restrictions here. > > I haven't thought too deeply on it either, but experience has shown that > there are always corner cases. As long as the initial implementation is > explicit about its use cases and errors on anything not tested, relaxing > it for future use cases is easier than allowing everything and using > policies to fix what is broken. > 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. > Thanks, > > --Ben > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
