Add Toolchain Class for GnuMake

[solvingj]

Changelog: Feature: Add an experimental toolchain for gnu make.
Docs: conan-io/docs#1808

Progresses #7280.

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

^{Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.}

[memsharded]

Looking very good, keep going. I am fine if the first iteration is basically this, it doesn't need to go much further to be included.

[memsharded]

Did some minor changes in #7435 that will affect this PR, please update when it is merged.

[solvingj]

@memsharded I've added proper handling to a bunch of important flags. Please review the diff of the latest commit if you can to get a feel for it. Let me know if you see any glaring issue.

[solvingj]

Just found issues, this is not ready yet.

[solvingj]

Recent test issues resolved. Taking out of draft status for CI to run.

[solvingj]

For future reference, this toolchain features a Make function called CONAN_TC_SETUP which works much like CONAN_BASIC_SETUP from the CMake generator which most people are familiar with. It is now also similar to CONAN_BASIC_SETUP in the Make generator which is pending in the following PR:
#7459

These Make functions automatically appends CONAN_ prefixed variables to the standard Make variables. For users who don't want this behavior, they can pick and choose how to use the individual CONAN_ variables manually in any way they wish.

[solvingj]

Added PR for docs: conan-io/docs#1808

[memsharded]

This is looking good, but I would try to have the generated toolchain files simpler. Users when reading those should be very easy and clear what the toolchain is doing, without really needing to mentally evaluate and understand a lot of conditionals that will evaluate always to the same thing.

What do you think @solvingj?

[memsharded]

Is this import necessary? We don't use this in the codebase

[solvingj]

It seemed it was necessary at the time. I will try to remove and see if it still works.

[memsharded]

I think it is better to simplify this, by adding the condition in the template:

• Do not need to define a CONAN_TC_SET_LIBCXX var.
• Use set_libcxx as a template condition to render or not certain parts of the template.
• The idea is that if not setting libcxx, then absolutely nothing will appear in the toolchain file, and it will be simpler.

[solvingj]

As discussed earlier I copied most of the patterns from the CMake toolchain for this first iteration.

[memsharded]

Something similar to the mapping from the CONAN_TC_LIBCXX to the final flag to be passed. It is likely that this is already somewhere in python. So maybe the final toolchain file could be something like just a single line defining the -library=xxx value, but without conditions at all?

[solvingj]

Same answer as above. Copied patterns from Cmake. Indeed, if we can release this first iteration, we can refactor the common code out together as one concerted initiative.

[memsharded]

These Make functions automatically appends CONAN_ prefixed variables to the standard Make variables. For users who don't want this behavior, they can pick and choose how to use the individual CONAN_ variables manually in any way they wish.

The idea is that this will be definitely possible, but controlled by the recipe toolchain, not at the build system level. Recipe toolchain defines if the vars are automatically injected or not, if certain behaviors (fpic, libcxx) are used or not, etc.

My feeling is that it is easier to control behavior, to introduce opt-ins/outs and fixes at the python toolchain() level than in the build system .mak files. It is also more transparent, e.g. if the toolchain() defines that fPIC is used, there shouldn't be an easy way to not use it at the build system level, otherwise there will be inconsistencies that are difficult to see and understand by package recipe creators and maintainers. Let's discuss it.

[solvingj]

The idea is that this will be definitely possible, but controlled by the recipe toolchain, not at the build system level. Recipe toolchain defines if the vars are automatically injected or not, if certain behaviors (fpic, libcxx) are used or not, etc.

Per @memsharded discussion on slack, we have a lot of feedback on the pattern of requiring a call to a macro in the build system to activate something in the files conan generated for the build system. The feedback is strong that transparency is most desirable, and calling the function explicitly is unacceptable in many cases.

I understand and recognize that feedback. So, I think the ability to make things transparent should always be a top priority. However, I think there should always be a reasonable way to opt-out of the full transparency, so I think the macros should always be available as an option.

@memsharded suggestion to add a toolchain option which sets the default activation status in the generated file makes sense to me, and I agree that in most OSS recipes, this would probably be True. Conversely, in private enterprise codebases, the implementation of Conan is often phased and gradual. In these cases, I can see many enterprises setting the this to False for private components so they can start generating and committing conan toolchain files to SCM using CI. Then, updating all their existing Makefiles to include these toolchain files across the codebase but without actually affecting builds at all. Once that is done, whomever is responsible for implementing Conan could go project-by-project and manually add the call to the macro for local testing. This lets them easily compare the flags or binaries built with and without the Conan toolchain variables and troubleshooting the difference. Once all the projects successfully build with Conan variables, and the time is appropriate, they could change all the recipes to begin generating and committing new toolchain files with default activation status to true, and thus making the use of Conan toolchains active across the codebase. The point of this very specific "scenario" is only to justify that the macro is still a good thing for phased migrations, and the key moving forward is finding the right control points (and I like the one suggested)

[memsharded]

As discussed, even if there are some things to change and improve, lets merge and release this as a first iteration, and start gathering feedback to keep this new experimental feature moving forward.