On 2/1/2019 3:04 PM, Peter Bindels wrote:
>
> As an extension to this, I've created Evoke that does the same basic
> derivation, but then does the whole build system part too. I've not
> yet used it widely enough - in part because I try not to convince
> coworkers to switch to a new tool every few months - but on the
> targets I've tried it on it works. Full stop.
Evoke still uses the directory structure to infer library names. So,
instead of dropping and dragging in an IDE you just put all your files
in directories with the names of the libraries you want. So, the user is
at that level giving some structure to the c++ source files it has.

> I doubt that. Shared libraries as a generic thing are a choice that
> needs a whole lot more thought than nearly all developers are putting
> into these choices; static by default is the only sane option.
That is not what linux distributions demand. They require that projects
almost exclusively use shared libraries and static linking is discouraged.

Anyway, Evoke and the other tool sound interesting and obviously work
well for some use cases.

I think the main point of this is that people should not have to declare
dependency information explicitly with modules and include files. On
that point, I think we are in full agreement.
> Do you wish the same upon C++, where parsing the code requires a full
> preprocessor and in many cases may not even reveal that a file is
> never built, built 4x with different options, or only on some
> platforms exports a given module? On sundays?

Actually I would not. I would rather modules not be added to C++.
However, it seems that the C++ module train is on the tracks with little
chance of being derailed. Given that modules are coming to C++ whether
I like it or not, I want to make sure that the compilers are able to
provide enough information to the build tools so that it can be
supported without having a c++ parser built into the tool like we
currently do for CMake and Fortran.

-Bill