Discussion:
Determination of default configuration values for build projects and checking the settings
SF Markus Elfring
2017-07-11 10:43:49 UTC
Permalink
Hello,

I find the following information interesting once more.
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Site-Defaults.html
“…
Autoconf-generated configure scripts allow your site to provide default values
for some configuration values. You do this by creating site- and system-wide
initialization files.
…”

1. Will it become possible to select such defaults only for specific software
build projects?

2. These values will be passed to configuration and make scripts.
How much do you trust that they are really usable?
If you would like to perform validation checks again, I am looking for ways
to avoid corresponding code repetition there.


I would appreciate further advice.

Regards,
Markus
Eric Blake
2017-07-11 11:27:52 UTC
Permalink
Post by SF Markus Elfring
Hello,
I find the following information interesting once more.
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Site-Defaults.html
“

Autoconf-generated configure scripts allow your site to provide default values
for some configuration values. You do this by creating site- and system-wide
initialization files.

”
1. Will it become possible to select such defaults only for specific software
build projects?
Unless someone writes a patch to autoconf (and then you propagate the
use of that new autoconf to all affected packages), it is only possible
to select per-package defaults insofar as those packages stick to
per-package cache variable names.
Post by SF Markus Elfring
2. These values will be passed to configuration and make scripts.
How much do you trust that they are really usable?
If you don't trust site-wide defaults, then don't install them.
Post by SF Markus Elfring
If you would like to perform validation checks again, I am looking for ways
to avoid corresponding code repetition there.
Site-wide defaults set cache variables in order to avoid repetitive
testing; but if you don't trust the installed site-wide defaults that
you get when you avoid the testing, then what DO you trust?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
SF Markus Elfring
2017-07-11 12:15:42 UTC
Permalink
Post by Eric Blake
Site-wide defaults set cache variables in order to avoid repetitive
testing; but if you don't trust the installed site-wide defaults that
you get when you avoid the testing, then what DO you trust?
How would you handle data format conversions for providers of configuration information?

Would you like to care for transition phases until a general agreement
could be achieved for blessed values by involved contributors for the
affected software area?

Regards,
Markus
Zack Weinberg
2017-07-11 15:20:16 UTC
Permalink
On Tue, Jul 11, 2017 at 8:15 AM, SF Markus Elfring
Post by SF Markus Elfring
Post by Eric Blake
Site-wide defaults set cache variables in order to avoid repetitive
testing; but if you don't trust the installed site-wide defaults that
you get when you avoid the testing, then what DO you trust?
How would you handle data format conversions for providers of configuration information?
Would you like to care for transition phases until a general agreement
could be achieved for blessed values by involved contributors for the
affected software area?
Could you back up a bit and tell us the original problem you are
trying to solve, please? What you are saying does not make very much
sense.

zw
SF Markus Elfring
2017-07-11 17:19:45 UTC
Permalink
Post by Zack Weinberg
Post by SF Markus Elfring
How would you handle data format conversions for providers of configuration information?
Would you like to care for transition phases until a general agreement
could be achieved for blessed values by involved contributors for the
affected software area?
Could you back up a bit and tell us the original problem you are
trying to solve, please?
Yes. - I am trying to convert a few build scripts from another
evolving free software to an Automake based approach.

See also:
Support for out-of-source builds by make scripts
https://github.com/ocaml/ocamlbuild/issues/245
Post by Zack Weinberg
What you are saying does not make very much sense.
I assume then that a bit more concrete background information can help
in a better understanding.


The following command is used there.
https://github.com/ocaml/ocamlbuild/blob/81f849564672b75d90ac04713f614ed77b5bd7dc/configure.make#L9


include $(shell ocamlc -where)/Makefile.config



This specification can be resolved to another make script which contains
the information “# generated by ./configure …” in the first line.
So I became curious on how such data can be transformed into desired
default configuration values in similar use cases.

Regards,
Markus

Loading...