Avoid using a bunch of cfg flags and use of hardcoded auto.conf path

[kloenk]

Currently, building with O=$something fails as auto.conf is search for in the source tree.
Also the arguments passed as cfg parsed from auto.conf can get bigger as the max argument length of linux.

[kloenk]

For configs, that are y, do we want to pass --cfg=name="y" or do we just want --cfg=name

[ojeda]

For configs, that are y, do we want to pass --cfg=name="y" or do we just want --cfg=name

Good question. On the C side we have the IS_BUILTIN/MODULE/REACHABLE/ENABLED macros as well as just #ifdef etc.

I guess for ease of use we could provide each CONFIG_X value for both the value and the "empty" value, i.e.:

• For y: CONFIG_X and CONFIG_X="y".
• For m: CONFIG_X and CONFIG_X="m".

We can forget about the IS_REACHABLE for the moment (one can always put the equivalent predicate if needed).

For other kinds of values (e.g. integers and strings), I don't think we want to set the CONFIG_X, but it does not hurt and would be consistent.

[ojeda]

For configs, that are y, do we want to pass --cfg=name="y" or do we just want --cfg=name

Good question. On the C side we have the IS_BUILTIN/MODULE/REACHABLE/ENABLED macros as well as just #ifdef etc.

I guess for ease of use we could provide each CONFIG_X value for both the value and the "empty" value, i.e.:

• For y: CONFIG_X and CONFIG_X="y".
• For m: CONFIG_X and CONFIG_X="m".

We can forget about the IS_REACHABLE for the moment (one can always put the equivalent predicate if needed).

For other kinds of values (e.g. integers and strings), I don't think we want to set the CONFIG_X, but it does not hurt and would be consistent.

This is handled by #32