Warum erkennt das Konfigurationsskript von Ruby meine ausführbaren Dateien und Header-Dateien nicht?

Warum erkennt das Konfigurationsskript von Ruby meine ausführbaren Dateien und Header-Dateien nicht?

Ich versuche, Ruby zu kompilieren und wirklich zu verstehen, was dabei passiert. Ich habe es Makefilesschon einmal verwendet und geschrieben, aber nicht autoconfdie Dateien von configure.in, also ist das Ergebnis, das ich erhalte, vielleicht beabsichtigt:

$ git clone https://github.com/ruby/ruby.git
...
$ cd ruby
$ git clean -fdx
$ autoconf 
$ ./configure
...
checking for dot... no
checking for doxygen... no
checking for pkg-config... no
...
checking direct.h usability... no
checking direct.h presence... no
checking for direct.h... no
...
checking for daemon... (cached) no

Allerdings sind alle davon zumindest installiert:

$ dot -V
dot - graphviz version 2.26.3 (20100126.1600)
$ doxygen --version
1.7.4
$ pkg-config --version
0.26
$ sudo updatedb
$ locate /direct.h
/usr/src/linux-headers-3.0.0-16-generic/include/config/pci/direct.h
/usr/src/linux-headers-3.0.0-17-generic/include/config/pci/direct.h
$ daemon --version
daemon-0.6.4

Mir ist klar, dass es für jeden dieser Fälle unterschiedliche Ursachen geben kann, aberwarum werden sie vom configureSkript nicht erkannt?

Ich verwende Ubuntu 11.10 mit den neuesten Patches.

$ uname -a
Linux username 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Auf einem anderen Host versucht. Von config.log:

configure:6408: checking for dot
configure:6424: found /usr/bin/dot
configure:6438: result: no
configure:6445: checking for doxygen
configure:6461: found /usr/bin/doxygen
configure:6475: result: no
configure:6483: checking for pkg-config
configure:6504: found /usr/bin/pkg-config
configure:6530: result: no

Was? Sie wurden gefunden, aber es geht immer noch nicht weiter?

configure:11880: checking direct.h usability
configure:11880: gcc -c  -O3 -ggdb    conftest.c >&5
conftest.c:135:20: fatal error: direct.h: No such file or directory
compilation terminated.
configure:11880: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
...
| #endif
| #include <direct.h>
configure:11880: result: no
configure:11880: checking direct.h presence
configure:11880: gcc -E  conftest.c
conftest.c:102:20: fatal error: direct.h: No such file or directory
compilation terminated.
configure:11880: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| /* end confdefs.h.  */
| #include <direct.h>
configure:11880: result: no
configure:11880: checking for direct.h
configure:11880: result: no

Funky Testskript – Vielleicht muss es sich in einer Art Standardpfad befinden?

configure:15175: checking for daemon
configure:15175: result: no

Es stellt sich heraus, dass dies nicht die Überprüfung einer ausführbaren Datei ist, sondern einer C-Funktion mitAC_CHECK_FUNCS.

Antwort1

Ich weiß fast nichts über Ruby. Ich weiß jedoch ziemlich viel über Build-Systeme. Ich werde mich hier weit aus dem Fenster lehnen und vorschlagenSie haben einen echten Fehler im Ruby-Build-System gefunden.

Hier ist meine Begründung:

  1. Ich erhalte das gleiche Ergebnis wie Sie, auf völlig unterschiedlichen Systemen (sogar Cygwin/Windows 7), sowohl mit dem von Ihnen angegebenen Git-Repo als auch mit demStandardquellen für Ruby 1.9

  2. found: /usr/bin/dotDer Grund, den Sie in Ihrem sehen, configure.log ist, dass es tatsächlich auf dem Pfad gefunden wurde. Dies ist im generierten configureSkript leicht zu erkennen, insbesondere wenn Sie die erste Zeile ändern, um #!/bin/sh -xeine Shell-Debug-Ausgabe zu erhalten:

    + test -z /bin
    + for ac_exec_ext in ''\'''\''' '$ac_executable_extensions'
    + test -f /bin/dot
    + test -x /bin/dot
    + ac_cv_prog_DOT=
    + printf '%s\n' 'configure:6424: found /bin/dot'
    + break 2
    + IFS='     
    
  3. Der Grund hierfür result: noist, dass, wie Sie dem obigen Snippet entnehmen können, ac_cv_prog_DOTauf eine leere Zeichenfolge gesetzt wurde und die folgenden Zeilen in der Konfiguration einfach diesen fehlenden Wert widerspiegeln:

    + DOT=
    + test -n ''
    + printf '%s\n' 'configure:6438: result: no'
    + printf '%s\n' no
    no
    
  4. Der Grund für die Einstellung auf einen leeren String ist (und das ist der springende Punkt), dass configure.inin Zeile 371 ein leerer String angegeben wurde:

    AC_CHECK_PROG(DOT, dot)
    AC_CHECK_PROG(DOXYGEN, doxygen)
    

    Ich glaube, das ist ein fehlerhafter Aufruf des Makros AC_CHECK_PROG, dasGNU Autoconf-Dokumenteangeben dauertdreierforderliche Argumente, nicht zwei:

    ― Macro: AC_CHECK_PROG (variable, prog-to-check-for, value-if-found, [value-if-not-found], [path = ‘$PATH’], [reject])
    
    Check whether program prog-to-check-for exists in path. If it
    is found, set variable to value-if-found, otherwise to
    value-if-not-found, if given. Always pass over reject (an
    absolute file name) even if it is the first found in the search
    path; in that case, set variable using the absolute file name
    of the prog-to-check-for found that is not reject. If variable
    was already set, do nothing. Calls AC_SUBST for variable. The
    result of this test can be overridden by setting the variable
    variable or the cache variable ac_cv_prog_variable.
    

    Es gibt keinen Standardwert. Wenn Sie ihn weglassen, bedeutet das: „Wenn Sie einen Punkt finden, setzen Sie DOT auf eine leere Zeichenfolge.“

  5. Ich glaube, der Grund für diesen Fehler lag darin, dass in der ursprünglichen Definition dieser Zeile ein anderes Makro verwendet wurde, AC_CHECK_TOOLdas nur zwei Argumente annimmt.

    Aus Check-in bei svn.ruby-lang.org am 11. November 2010

    AC_CHECK_TOOL wird zu AC_CHECK_PROG am

  6. Möglicherweise ist dies schon seit einiger Zeit nicht mehr bekannt und einige ChangeLog-Kommentare scheinen darauf hinzudeuten, dass es Probleme mit gab DOXYGEN, zum Beispiel:

    Fri Mar 26 19:55:41 2010  Akinori MUSHA  <[email protected]>
    
        * Makefile.in (DOXYGEN): Define a missing variable DOXYGEN.  Build
          has been failing when doxygen(1) is found by configure but the
          variable is not defined by the system and make(1) does not allow
          an empty command. ("@$(DOXYGEN)" was the cause)
    

Schließlich ist es möglich, dass ich das alles falsch verstanden habe. Aber ich bin ziemlich sicher, dass configurediese Tools gefunden werden und dass die Anweisung gegeben wurde, die entsprechenden Makefile-Variablen auf leere Zeichenfolgen zu setzen.

Ich bin gespannt, was andere von dieser Analyse halten.

verwandte Informationen