Open robertodr opened 6 years ago
I agree about the redundancy but do not agree that you did a sloppy job :-) Let us automatically fetch these. Should these files still reside under modules/
and be fetched to downloaded/
? In other words should the only API change be a simplification of the yaml recipe? I think so but wanted to get your view first before starting hacking.
Yes, I agree with you. Only YAML simplification. The checks on CMAKE_<LANG>_COMPILER_WORKS
should go in <lang>.cmake
should go away too.
@bast I'll try to submit a PR today.
I am unsure about one thing: I had this fc_optional. This was for libraries that are mostly used out of C/C++ but sometimes used from Fortran. I have learned that Fortran is not a standard thing on Mac so I wanted to keep it optional to not force Mac people to install Fortran if the library does not need it. What is your view on this? Should we allow optional languages?
My view is that fc_optional
is fine as is. I don't think we need equivalent cc_optional
and cxx_optional
though.
OK I agree. So if you work on this, please either make sure that fc_optional still works. But if it gets too clunky and weird, then I am not too attached to it and we can also retire it.
I'm hitting a problem and I don't know what's the best way to solve it. So once the language(s) for the project have been read in the YAML, I generate the list of modules to automatically include. This list has to be injected into the config
read from the YAML file. This means:
update.py
script. This means that testing local changes of cc.cmake
, cxx.cmake
and fc.cmake
will no longer be possible.autocmake.yml
after they've been read in, meaning that what the user provides is not exactly what will be used to generate CMakeLists.txt
.How should I/we proceed?
Hmm ... difficult. I need to think more about this. Tricky. One problem of hardcoding this is that it would make it hard for people to adapt these modules (perhaps they would like to change the flags that come with these modules). Another thought is https://github.com/coderefinery/autocmake/issues/214.
Already now we have some components that are always injected: https://github.com/coderefinery/autocmake/blob/master/autocmake/generate.py#L79-L86 Perhaps we should consider the compiler setup flags as fixed.
If we consider them fixed, perhaps we should remove the lang enabling modules from modules/
and hide it inside autocmake?
Perhaps the current solution of forcing people to specify project()
langs in combination of giving optional modules which handle some useful flags is not too bad?
I am not sure, just throwing here some thoughts that I need to digest myself.
I always feel a bit uncomfortable with hidden actions but perhaps it makes sense here.
Thinking more about this, a setup script for a C/CXX project without --cc/--cxx flags is weird so it is not completely optional. Also these are pretty standard names and we can consider them fixed I think. Let us perhaps first think what we want to be fixed and what we want to be customizable. Once we have that defined we can think about how we accommodate it.
To add some confusion :-) yet another alternative could be to set LANGUAGE to NONE in project() and enable them one by one explicitly, see https://cmake.org/cmake/help/v3.0/command/project.html, quoting: "By default C and CXX are enabled if no language options are given. Specify language NONE, or use the LANGUAGES keyword and list no languages, to skip enabling any languages."
Yes, just saw that. And now I am wondering if we should have NONE
as default and do enable_language
. Let's sit on this for a little longer.
Agree, let's sleep on it few times to get it right.
The code duplication is still a bit of a sore point and I think we agree that we don't want to keep the current state. I think both strategies are possible and I will try to summarize advantages/disadvantages:
Advantages:
Disadvantages:
Advantages:
Disadvantages:
I introduced the
language
section inautocmake.yml
to obviate to the fact thatenable_language
andproject(<name> <languages>)
do not exactly generate the same build system. The consensus we reached at the time was thatenable_language
is better left for optionally enabling one or more languages, see for example thefc_optional.cmake
file. I think, however, that I did a sloppy job, since users of Autocmake now have to have the following lines in theirautocmake.yml
:The explicit inclusion of
fc.cmake
,cc.cmake
andcxx.cmake
is, in my opinion, completely redundant. It should be possible to:python update.py ..
fc.cmake
,cc.cmake
andcxx.cmake
. The checks onCMAKE_<LANG>_COMPILER_WORKS
are performed by CMake already, for example.