Add metacg-config tool

[sebastiankreutzer]

This patch adds metacg-config, a lightweight tool inspired by scorep-config that can be used to print relevant information about the package.
As a start, the options --version, --revision and --prefix are supported.

The main reason I added this was to make integration of compiler passes (e.g. from cgpatch and later CaGe) easier for the user.
For example, to compile with cgpatch, one could use: clang++ $(metacg-config --cgpatch-cxxflags) input.cpp

[jplehr]

I think this should also go into the existing tools folder instead.

[sebastiankreutzer]

I think this should also go into the existing tools folder instead.

My rationale was that it is not a "tool" like the other existing tools, as it does not use the graph lib in any way.
Also, I think it should not be tied to the METACG_BUILD_GRAPH_TOOLS option, as it is useful even if none of the tools are built.

[sebastiankreutzer]

Maybe a util folder would be a suitable alternative?

[jplehr]

I think this should also go into the existing tools folder instead.

My rationale was that it is not a "tool" like the other existing tools, as it does not use the graph lib in any way. Also, I think it should not be tied to the METACG_BUILD_GRAPH_TOOLS option, as it is useful even if none of the tools are built.

Understood. I mostly want to prevent that we start littering the top-level with stuff for everything that is "not quite the same" as to what is already in tree. Do we have other things that are planned to come into MetaCG that are mostly utils?
The CMake target collector util might be another of such utils. That would warrant a TLD utils I suppose.

[sebastiankreutzer]

I think this should also go into the existing tools folder instead.

My rationale was that it is not a "tool" like the other existing tools, as it does not use the graph lib in any way. Also, I think it should not be tied to the METACG_BUILD_GRAPH_TOOLS option, as it is useful even if none of the tools are built.

Understood. I mostly want to prevent that we start littering the top-level with stuff for everything that is "not quite the same" as to what is already in tree. Do we have other things that are planned to come into MetaCG that are mostly utils? The CMake target collector util might be another of such utils. That would warrant a TLD utils I suppose.

We just had a brief discussion about this with @TimHeldmann and @pearzt. The consensus was that:

• It should not go into tools, as it is a project-scope utility, not a graphlib one.
• There are currently no other utilities of this kind, so adding an additional utils folder is a bit premature. If we change our mind or other such utilities are added, we can easily move it.

[jplehr]

I think this should also go into the existing tools folder instead.

My rationale was that it is not a "tool" like the other existing tools, as it does not use the graph lib in any way. Also, I think it should not be tied to the METACG_BUILD_GRAPH_TOOLS option, as it is useful even if none of the tools are built.

Understood. I mostly want to prevent that we start littering the top-level with stuff for everything that is "not quite the same" as to what is already in tree. Do we have other things that are planned to come into MetaCG that are mostly utils? The CMake target collector util might be another of such utils. That would warrant a TLD utils I suppose.

We just had a brief discussion about this with @TimHeldmann and @pearzt. The consensus was that:

• It should not go into tools, as it is a project-scope utility, not a graphlib one.
• There are currently no other utilities of this kind, so adding an additional utils folder is a bit premature. If we change our mind or other such utilities are added, we can easily move it.

What about the TargetCollector.py? Isn't this a util?

[sebastiankreutzer]

I think this should also go into the existing tools folder instead.

My rationale was that it is not a "tool" like the other existing tools, as it does not use the graph lib in any way. Also, I think it should not be tied to the METACG_BUILD_GRAPH_TOOLS option, as it is useful even if none of the tools are built.

Understood. I mostly want to prevent that we start littering the top-level with stuff for everything that is "not quite the same" as to what is already in tree. Do we have other things that are planned to come into MetaCG that are mostly utils? The CMake target collector util might be another of such utils. That would warrant a TLD utils I suppose.

We just had a brief discussion about this with @TimHeldmann and @pearzt. The consensus was that:

• It should not go into tools, as it is a project-scope utility, not a graphlib one.
• There are currently no other utilities of this kind, so adding an additional utils folder is a bit premature. If we change our mind or other such utilities are added, we can easily move it.

What about the TargetCollector.py? Isn't this a util?

I guess I considered TargetCollector.py a cgcollector specific feature that should really have been placed into cgcollector.
But looking at it now, it should also work with the graph tools.
So I'm happy to move into a common utils folder.

[jplehr]

I think this should also go into the existing tools folder instead.

My rationale was that it is not a "tool" like the other existing tools, as it does not use the graph lib in any way. Also, I think it should not be tied to the METACG_BUILD_GRAPH_TOOLS option, as it is useful even if none of the tools are built.

Understood. I mostly want to prevent that we start littering the top-level with stuff for everything that is "not quite the same" as to what is already in tree. Do we have other things that are planned to come into MetaCG that are mostly utils? The CMake target collector util might be another of such utils. That would warrant a TLD utils I suppose.

We just had a brief discussion about this with @TimHeldmann and @pearzt. The consensus was that:

• It should not go into tools, as it is a project-scope utility, not a graphlib one.
• There are currently no other utilities of this kind, so adding an additional utils folder is a bit premature. If we change our mind or other such utilities are added, we can easily move it.

What about the TargetCollector.py? Isn't this a util?

I guess I considered TargetCollector.py a cgcollector specific feature that should really have been placed into cgcollector. But looking at it now, it should also work with the graph tools. So I'm happy to move into a common utils folder.

I personally would treat both of those tools as utils.