[cmake-developers] Referencing all sources in compile command

[Ben Boeckel]

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.

> On Mon, Dec 31, 2018 at 2:17 PM Ben Boeckel <ben.boeckel at 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.

Thanks,

--Ben