[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to support compilers that cannot create executables?

From: Steffen Dettmer
Subject: Re: how to support compilers that cannot create executables?
Date: Wed, 23 Sep 2009 13:34:57 +0200

On Mon, Sep 21, 2009 at 7:37 PM, <address@hidden> wrote:
> * Steffen Dettmer wrote on Mon, Sep 21, 2009 at 10:24:26AM CEST:
> > > If you cannot write such a wrapper, then it probably makes
> > > just as much sense to pre-seed a file with
> > > cache variables containing the correct answers for this
> > > compiler.
> >
> > I'm afraid I don't understand. You mean, we could write the
> > results of some specific tests in advance?
> Yes.
> > What kind of test
> > results could that be? What would be the advantage? Even with the
> > same compiler, results vary.
> For such a configuration, you could take all the cache variables of
> all the relevant tests, and pre-seed them.
> Then you can load that site file and work with that
> configuration.

I think I /technically/ understand what you explain. We have
typically 40 sub-configures, where first exports include paths
for 39 subsequent, 2nd for 38 and so on - using cache variables.
When an export changes, the cache variable is updated and without
calling predecessor-config the importing module is up-to-date.
Saves much time on cygwin. Similar to that we could have a
component setting all the cache variables, ok.

But what should this help? We had to write the tests ourselfs
(just not inside autoconf) to seed the values?

So /logically/ I don't understand. We use autoconf to find out if
we have printf and/or malloc and so on. We do not want to
manually have to tell if we have it or not.

Writing the test results in advance seems to render the whole
test a bit useless?

> Recent git Autoconf has added documentation for many cache variables;
> but even if you don't know them, you can do a configure run for a very
> similar configuration and adjust the results that come out wrong;
> that'll usually come close.

You mean someone could manually change config.status or Wouldn't this be horrible and violating
reproducibility? Or would this site file be included in version
control and source dist?

I think, when building, no adjustments are allowed. In case of a
problem the sources have to be fixed, a new tag must be set and
the build started again from scratch.

Also, I think, may not be suited for cross-compiling.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]