Re: CFO: Why ./configure?
From: VBDis (vbdis_at_aol.com)
Date: 09/10/03
- Next message: Erik Max Francis: "Re: CFO: Why ./configure?"
- Previous message: VBDis: "Re: CFO: Why C?"
- In reply to: Erik Max Francis: "Re: CFO: Why ./configure?"
- Next in thread: Erik Max Francis: "Re: CFO: Why ./configure?"
- Reply: Erik Max Francis: "Re: CFO: Why ./configure?"
- Reply: Thomas Richter: "Re: CFO: Why ./configure?"
- Reply: Ulrich Eckhardt: "never set CC, LDFLAGS et al like this [Was: Re: CFO: Why ./configure?]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 09 Sep 2003 23:37:28 GMT
Im Artikel <3F5B914A.B4C14A87@alcyone.com>, Erik Max Francis <max@alcyone.com>
schreibt:
>As a trivial example, different platforms require different command line
>options to build shared libraries, for instance.
That's what "libtool" should equalize?
>You can't get that with symbolic links on your filesystem.
Isn't it possible to write a shell script, that translates the given switches
before passing the results to the platform specific tools?
AFAIK "make" also can include files, so that platform specific settings only
require links to files or directories, where the include files with the
platform specific settings reside. Currently configure does e.g. the following:
In Makefile.in the lines
CC = @CC@
LDFLAGS = @LDFLAGS@
libdir = @libdir@
are substituted in the created Makefile by e.g.
CC = gcc
LDFLAGS = -a
libdir = ${exec_prefix}/lib
Then what's wrong with placing all these platform specific constant
declarations into one platform specific config file, and have in the Makefile
include $(target)/config
At least would the use of such an config file reduce the amount of actions,
which configure actually performs. Have you concrete examples for things, which
then still remain to do for configure?
>Wouldn't it be more constructive to learn more about the reason for the
>existence of these systems before arguing that they're totally
>unnecessary?
My intention really is to learn more about configure and that stuff. But since
it's quite a complex matter, I tend to mix up the various aspects and confuse
the discussion. Sorry :-(
Let me try to specify the most important aspects:
1) What configure /can/ do. IMO "almost everything" would be a sufficient
answer?
2) What configure /must/ do. This is what I want to learn.
3) /How/ configure does it. This is where my own ideas come in, and where I
want to learn why things can be done /only/ in the currently implemented way.
I had not started this thread if I did not really have so many problems in only
making configure work on my system. There exist several solutions:
- Do it manually, by editing the buggy configure scripts etc. of every single
package.
- Let a tool do the same.
- Modify the build process to reduce the chances for errors.
>From my according observations and investigations I have some ideas where
problems reside, which are not noticeable as long as everything works fine, on
most other platforms. Now I'm searching for ways how to make the build process
even more flexible and possibly simpler at the same time. It may be impossible
to transform an Makefile.am into an Makefile in a single simple step, but every
simplification of that procedure would help the authors as well as the users of
software packages. So please help me in separating of what's possible from
what's impossible to improve on that way.
DoDi
- Next message: Erik Max Francis: "Re: CFO: Why ./configure?"
- Previous message: VBDis: "Re: CFO: Why C?"
- In reply to: Erik Max Francis: "Re: CFO: Why ./configure?"
- Next in thread: Erik Max Francis: "Re: CFO: Why ./configure?"
- Reply: Erik Max Francis: "Re: CFO: Why ./configure?"
- Reply: Thomas Richter: "Re: CFO: Why ./configure?"
- Reply: Ulrich Eckhardt: "never set CC, LDFLAGS et al like this [Was: Re: CFO: Why ./configure?]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
