Co to są Makefile.am i Makefile.in?

335

Te dwa pliki są najczęściej widoczne w projektach open source.

Do czego służą i jak działają?

makefile autotools automake Maska
źródło

Odpowiedzi:

381

Makefile.amPlik jest programator zdefiniowane i wykorzystywane jest przez automakewygenerować Makefile.inplik ( .ampodpórek na uto m ake). configureSkrypt zazwyczaj postrzegane w tarballs źródłowych użyje Makefile.indo wygenerowania Makefile.

configureSkrypt sam jest generowany z pliku o nazwie zdefiniowanej przez programistę albo configure.acalbo configure.in(niezalecane). Wolę .ac(do uto c ONF), ponieważ odróżnia go od generowanych plików iw ten sposób mogę mieć zasady, takie jak , która biegnie . Ponieważ jest to plik generowany, zwykle nie jest przechowywany w systemie wersji, takim jak Git, SVN, Mercurial lub CVS, a raczej plik.Makefile.inmake dist-cleanrm -f *.in.ac

Przeczytaj więcej na temat GNU Autotools . Przeczytaj informacje na temat makei Makefilepierwszy, a następnie dowiedzieć się o automake, autoconf, libtool, itd.

Sean AO Harney
źródło
3
Co oznacza .inskrót
Utku
10
Te .inśrodki przedłużające że to wejście do configuremasażu, a nie ostatecznego pliku, który ma zostać użyty (np make). Jeśli zastanawiasz się, dlaczego wydaje się to „absurdalnie” skomplikowane, spróbuj przeczytać: stackoverflow.com/a/26832773/939557 Obecnie GitHub itp. Staje się wspólnym kanałem dystrybucji. Niektóre założenia Autoconf załamują się: ludzie zdobywają źródło bezpośrednio z narzędzia do kontroli kodu źródłowego, zamiast używać tarballa dystrybucji źródła utworzonego przez opiekunów.
MadScientist
53

Prosty przykład

Bezwstydnie zaadaptowane z: http://www.gnu.org/software/automake/manual/html_node/Creating-amhello.html i przetestowane na Ubuntu 14.04 Automake 1.14.1.

Makefile.am

SUBDIRS = src
dist_doc_DATA = README.md

README.md

Some doc.

configure.ac

AC_INIT([automake_hello_world], [1.0], [[email protected]])
AM_INIT_AUTOMAKE([-Wall -Werror foreign])
AC_PROG_CC
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([
 Makefile
 src/Makefile
])
AC_OUTPUT

src / Makefile.am

bin_PROGRAMS = autotools_hello_world
autotools_hello_world_SOURCES = main.c

src / main.c

#include <config.h>
#include <stdio.h>

int main (void) {
  puts ("Hello world from " PACKAGE_STRING);
  return 0;
}

Stosowanie

autoreconf --install
mkdir build
cd build
../configure
make
sudo make install
autoconf_hello_world
sudo make uninstall

To daje:

Hello world from automake_hello_world 1.0

Notatki

  • autoreconf --installgeneruje kilka plików szablonów, które powinny być śledzone przez Git, w tym Makefile.in. Należy go uruchomić tylko za pierwszym razem.

  • make install instaluje:

    • plik binarny do /usr/local/bin
    • README.md do /usr/local/share/doc/automake_hello_world

Na GitHub możesz wypróbować.

Ciro Santilli
źródło
1
Dlaczego należy zachować generowane pliki w VCS (może to być nie tylko Git BTW)?
Victor Yarema
@VictorYarema Zapomniałem, dlaczego doszedłem do tego wniosku! Daj mi znać, jeśli się dowiesz.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
19

DEVELOPER działa autoconfi automake:

1) autoconf - tworzy wysyłalny skrypt konfiguracyjny
(który później instalator uruchomi, aby utworzyć plik Makefile )

2) automake - tworzy wysyłalny plik danych Makefile.in
( konfiguracja zostanie później odczytana, aby utworzyć plik Makefile )

INSTALATOR biegnie configure, makei sudo make install:

./configure       # Creates  Makefile        (from     Makefile.in).  
make              # Creates  the application (from the Makefile just created).  

sudo make install # Installs the application 
                  #   Often, by default its files are installed into /usr/local

MAPA WEJŚCIA / WYJŚCIA

Poniższy zapis jest z grubsza: dane wejściowe -> programy -> dane wyjściowe

DEVELOPER uruchamia te:

configure.ac -> autoconf -> configure (skrypt) --- (*. ac = a uto c onf)
configure.in -> autoconf -> configure (skrypt) --- ( configure.innieaktualne. Użyj config.ac)

Makefile.am -> automake -> Makefile.in ----------- (*. Am = a uto m ake)

INSTALLER uruchamia te:

Makefile.in -> Konfiguracja -> Makefile (. * W = w pliku put)

Makefile -> make ----------> (umieszcza nowe oprogramowanie w plikach do pobrania lub katalogu tymczasowym)
Makefile -> make install -> (umieszcza nowe oprogramowanie w katalogach systemowych)

„ autoconf jest rozszerzalnym pakietem makr M4, które tworzą skrypty powłoki do automatycznego konfigurowania pakietów kodu źródłowego oprogramowania. Skrypty te mogą dostosowywać pakiety do wielu rodzajów systemów typu UNIX bez ręcznej interwencji użytkownika. Autoconf tworzy skrypt konfiguracyjny dla pakietu z plik szablonu zawierający listę funkcji systemu operacyjnego, z których pakiet może korzystać, w postaci wywołań makr M4 ”.

„ automake jest narzędziem do automatycznego generowania plików Makefile.in zgodnych ze standardami kodowania GNU. Automake wymaga użycia Autoconf.”

Instrukcje:

Darmowe samouczki online:

Przykład:

Główny plik configure.ac użyty do budowy LibreOffice ma ponad 12 000 wierszy kodu (ale w podfolderach znajduje się również 57 innych plików config.ac).

Z tego moja wygenerowana konfiguracja zawiera ponad 41 tys. Linii kodu.

I podczas gdy Makefile.in i Makefile są tylko 493 liniami kodu. (Ale w podfolderach jest także 768 dodatkowych plików Makefile.in).

Widok eliptyczny
źródło
16

referencja :

Makefile.am - plik wejściowy użytkownika do zautomatyzowania

configure.in - plik wejściowy użytkownika do autoconf

autoconf generuje config z configure.in

automake gererates Makefile.in z Makefile.am

configure generuje Makefile z Makefile.in

Na przykład:

$]
configure.in Makefile.in
$] sudo autoconf
configure configure.in Makefile.in ... 
$] sudo ./configure
Makefile Makefile.in

źródło
Zatem Makefile.in powinien znajdować się w pliku tar.gz podczas tworzenia dist, prawda?
Kemin Zhou