Date: Fri, 1 Feb 2019 13:31:48 +0100
I agree with the vast majority of Lazăr, that encoding things twice is redundant and error prone, and also CMake is not something I would like to live with in the long run. I do have to give meson and build2 a spin some time. (I have already expressed my ideas of an extensible, tool and language aware build system, so I won’t repeat.) However, tooling cannot leave behind legacy codebases, so they do have to deal with all sorts of layout and coding style. The approach taken by akro is nice, but then I’d ask: why not go all the way and mandate „#pragma lib” as done by MSVC? Why must the library (filename) be implicit when the interface header (filename) is explicit? Converting existing code to using any other style than they are using today will cause immense friction and fragmantation. CMake succeeded because it caters to most use cases.
Having that said, with the second layer of dependency tracking and compilation is no pain if a tool takes care of it. If you use Visual Studio, you just add the file in Solution Explorer and the MSBuild .vcxproj file is automatically updated to compile it. CLion can do something very similar with CMake scripts even.
TL;DR: I don’t care that build definitions exist if I’m not the one who authors them.
Feladó: Boris Kolpackov
Elküldve: 2019. február 1., péntek 7:58
Címzett: WG21 Tooling Study Group SG15
Tárgy: Re: [Tooling] Modules
Dorin Lazar <dorin.lazar_at_[hidden]> writes:
> [...] you basically specify an „entry point”, and then assumes that if
> you #include "utils/string_utils.h" you might have a "utils/string_utils.cpp"
> to contain the code described in the "utils/string_utils.h".
Another approach with the same end-result is globbing (potentially
recursive). Neither covers everything 100% (auto-generated source
code is a notable issue) but I agree, not having to touch your
buildfiles every time you add a source file to a project has been
liberating.
_______________________________________________
Tooling mailing list
Tooling_at_[hidden]
http://www.open-std.org/mailman/listinfo/tooling
Having that said, with the second layer of dependency tracking and compilation is no pain if a tool takes care of it. If you use Visual Studio, you just add the file in Solution Explorer and the MSBuild .vcxproj file is automatically updated to compile it. CLion can do something very similar with CMake scripts even.
TL;DR: I don’t care that build definitions exist if I’m not the one who authors them.
Feladó: Boris Kolpackov
Elküldve: 2019. február 1., péntek 7:58
Címzett: WG21 Tooling Study Group SG15
Tárgy: Re: [Tooling] Modules
Dorin Lazar <dorin.lazar_at_[hidden]> writes:
> [...] you basically specify an „entry point”, and then assumes that if
> you #include "utils/string_utils.h" you might have a "utils/string_utils.cpp"
> to contain the code described in the "utils/string_utils.h".
Another approach with the same end-result is globbing (potentially
recursive). Neither covers everything 100% (auto-generated source
code is a notable issue) but I agree, not having to touch your
buildfiles every time you add a source file to a project has been
liberating.
_______________________________________________
Tooling mailing list
Tooling_at_[hidden]
http://www.open-std.org/mailman/listinfo/tooling
Received on 2019-02-01 13:38:19