Re: [cmake-developers] How to speed up CMake configuration on macOS
On Sat, Mar 23, 2019 at 15:07:39 +0100, Gregor Jasny via cmake-developers wrote: > in the past when building CMake (itself) I spent long times waiting for > configuration of the embedded libraries. Mostly libcurl send / receive > signature detection. Today I had the idea of using system libraries > installed with Homebrew and the speedups are quite noticeable: One thing I'd like to see here is to take a survey of what `send` and `recv` signatures actually exist in the wild today. We can then remove those `try_compile` runs from CMake's import. Further work would be to have `libcurl` upstream do this survey too (though this is a wider set of platforms than even CMake supports) and remove those which don't actually appear in the wild today. In addition, the attempts can be ordered based on platform and short circuit once one is found since `send` can have only one actual definition. --Ben -- 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
Re: [cmake-developers] Question about fetching big repositories with ExternalProject_Add
On Mon, Mar 11, 2019 at 16:50:21 +0100, workbe...@gmx.at wrote: > i play around much with ExternalProject_Add and i found some kind of > "error". When fetching big repositories like llvm cmake don't show any > output when cloning the repository which makes the user believe cmake > stucks, is there a way to show the clone process with > ExternalProject_Add() so the user does not believe cmake is stuck ?? > It's find with normal repositories, but for example with llvm it's a > nightmare. There's the `GIT_PROGRESS 1` argument you can pass. --Ben -- 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
Re: [cmake-developers] $LIST_LENGTH{} syntax
On Tue, Jan 22, 2019 at 19:31:43 +0100, tors...@robitzki.de wrote:
> Currently, the Code that evaluates the ${}-Syntax only evaluates the key, if
> the key is not an empty string:
>
> const char* cmCommandArgumentParserHelper::ExpandSpecialVariable(
> const char* key, const char* var)
> {
> if (!key) {
> return this->ExpandVariable(var);
> }
> if (!var) {
> return "";
> }
> if (strcmp(key, "ENV") == 0) {
> std::string str;
> if (cmSystemTools::GetEnv(var, str)) {
> if (this->EscapeQuotes) {
> return this->AddString(cmSystemTools::EscapeQuotes(str));
> }
> return this->AddString(str);
> }
> return "";
> }
> if (strcmp(key, „CACHE") == 0) {
>
> …
>
> so, there seems to be no risk to slow down the ExpandVariable()-Path (but of
> cause, I would measure the difference).
That's the old (pre-CMP0053) parser. The new code for handling the
`$XXX{` parse switching is in `Source/cmMakefile.cxx:2810` (or so). The
method is `cmMakefile::ExpandVariablesInStringNew`. It is very
performance sensitive (i.e., the old parser is so slow compared to the
new one that running the new one beside it doesn't really affect
performance much and is what allows for CMP0053 warning messages).
--Ben
--
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
Re: [cmake-developers] Referencing all sources in compile command
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 -o -emit-module-path > .swiftmodule -emit-module-doc-path .swiftdoc > > > 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 `` would be suitable. However, it might need to be `` 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 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 -- 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
Re: [cmake-developers] Referencing all sources in compile command
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? > 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 `` 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. 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? - If the latter, how do mixed language libraries work? - 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)? The list of restrictions would need to be well-defined here first I think. --Ben -- 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
