我如何创建一个配置脚本？

小开

最佳答案

To create the standard "configure" script you need GNU autoconf. You may need GNU automake and libtool too.

There are tons of documentation and howtos. Google for something like "autoconf automake howto". The good documentation is in the official manual pages:

Autoconf: http://www.gnu.org/software/autoconf/
Automake: http://www.gnu.org/software/automake/automake.html
Libtool: http://www.gnu.org/software/libtool/libtool.html

Autoconf will create your configure script starting from the "configure.ac" file. The "Makefile.am" file will instruct automake on how to create your makefile by the configure string. Libtool is needed to simplify libraries handling around your code.

You can start creating a configure.ac file by hand or you may use the "autoscan" helper that may help you to create something semi-automatic for you.

Then, when you are ready, this one will do the magic:

autoreconf -i

小开

there is build flow in linux
and there is a very good tutorial
https://thoughtbot.com/blog/the-magic-behind-configure-make-make-install

小开

Sometimes a software product will ship with no configure script. Look for an autogen.sh script. it will probably run:

aclocal || die "aclocal failed"
automake --add-missing --force-missing --copy --foreign || die "automake failed"
autoreconf || die "autoreconf failed"

小开

All of these answers are about autoconf which is a GNU tool. However, configure shell scripts have been in UNIX long before GNU and can be created by hand or in other ways.

What does configure do?

configure is a just shell script. It's job is to generate a list of configuration variables that the makefile needs to build the software on that particular system. For example, it might determine the linker flags and header search paths needed to include a specific library.

configure can also accept options from the user, for example to control whether to build in debug or release mode.

Typically configure writes these variables to a file called config.mk which is included by the makefile. It may also generate a header config.h with some preprocessor defines. Note that configure is just a helpful automation for producing this. The user can always just hand edit config.mk themselves (especially on obscure systems).

How does configure detect features?

configure uses a variety of techniques to locate dependencies and detect system or hardware features. The least stable (but sometimes necessary way) is to check the uname to detect and operating system. One useful tool is pkg-config which can tell you where to find various installed libraries.

Lastly, configure scripts can always generate small snippets of code, and then trying to compile them to see if a feature is available.

Joe Nelson has a great article with examples for each of these ideas.

Should I write my own configure or use autoconf?

Most programs only have 1 or 2 small things they need to detect to get working. I think it makes sense to write a configure script in these cases, rather than try to figure out corner cases of the massive piece of software that is autotools. If you product a simple config.mk it can always be fixed by hand, and users of various systems will be helpful in getting your configure to work correctly.

For more complex dependencies, autoconf is probably useful.

To be fair to all parties, let's relate the argument made in autoconf's documentation:

The primary goal of Autoconf is making the user’s life easier; making the maintainer’s life easier is only a secondary goal.

Autoconf is highly successful at its goal—most complaints to the Autoconf list are about difficulties in writing Autoconf input, and not in the behavior of the resulting configure. Even packages that don’t use Autoconf will generally provide a configure script, and the most common complaint about these alternative home-grown scripts is that they fail to meet one or more of the GNU Coding Standards (see Configuration in The GNU Coding Standards) that users have come to expect from Autoconf-generated configure scripts.

To summarize:

your configure might not have all the commands some users expect.
You might detect features incorrectly or using incorrect assumptions for example if macOS { use mac commands } else { use linux commands }, instead of if gnuTools { use gnu commands } else { use bsd/posix commands }.

You will have to determine whether that's important to you.