[cmake-developers] Referencing all sources in compile command

[Saleem Abdulrasool]

Responses inline.

On Mon, Dec 31, 2018 at 2:17 PM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Sun, Dec 30, 2018 at 13:09:23 -0800, Saleem Abdulrasool wrote:
> > I was looking at supporting Swift as a language in CMake.  I know that
> > CMake has some preliminary support that assumes that you are building on
> > macOS with Xcode.  I am trying to support building swift libraries and
> > executables on Linux and Windows.
>
> IIRC, the issue before was that the command line interface to swiftc was
> basically treated as a black box and not stable (i.e., whatever Xcode
> wanted drove the interface, backwards compat was not guaranteed). Is
> that different now?
>

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.

> There is some preliminary work on this that I have put up on GitHub [1].
> > One place that I am hitting a roadblock in is the need to reference all
> the
> > target sources in the compile rule for a single object.  AFAICT, there is
> > no placeholder that will expand to the target sources.  Would it be
> > acceptable to add a `<TARGET_SOURCES>` place holder?  Or is there another
> > approach that would be better?
>
> The problem with that is that per-source file properties cannot be
> applied (compile definitions, flags, etc.). I don't know whether or not
> this is important for Swift.
>

I think that there is some confusion over what exactly I need.  I am trying
to do file at a time compilation, but, each compilation requires the full
set of sources to be provided to the driver.  This effectively boils down
to:

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.


> 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.

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.

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.


> --Ben


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181231/12db1cf8/attachment.html>