Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Saturday, January 06, 2007
Batalla contra las autotools
Si toda la vida has sido un programador en Windows y ahora estás cambiándote a Linux, es muy probable que te encuentres en la situación de que tienes que lidiar con unas herramientas de construcción y compilado de aplicaciones comunmente denominadas "AutoTools", las cuales son un conjunto de scripts comunmente utilizados en el mundo GNU, como automake, autoconf, sistemas de macros M4, etc. para generar Makefiles.
Bueno, yo no es que haya sido "toda la vida" un programador de Windows, sino que en mis pocos años de mi experiencia como programador, los iniciales han sido como usuario de Windows, pero con herramientas de programación poco asociadas a entornos Windows, como Modula2, Hope, Java, C, C++ (los programadores de Windows más curtidos son sin embargo muy expertos en Visual C++, librerías STL, MFC's, etc.).
La cuestión es que, incluso aunque soy un acérrimo usuario de la plataforma .NET para desarrollar, como me gusta Mono tiendo a falimiarizarme con Linux y las autotools son unas de esas herramientas, algo antiguas, que incluso se siguen utilizando en desarrollos más modernos hechos con Mono. Un par de notorios ejemplos pueden ser Banshee y MonoDevelop.
Estas herramientas quizás fueran útiles en el pasado, sobre todo porque no había alternativas. Pero hoy día parecen un parásito feo y horrible que no se acaba de desligar del mundo GNU, a pesar de que hay buenas alternativas ya.
Los inconvenientes que le veo:
- La curva de aprendizaje es exageradamente pronunciada.
- No tienen una forma común de gramática/sintaxis para cada una de las sub-herramientas.
- No son multiplataforma, pues para su ejecución en entornos Windows se requiere de Cygwin.
También puede ocurrir que tampoco tengamos excesivo interés en lidiar con ellas, y de hecho te puedes convertir perfectamente en un colaborador de proyectos libres sin problemas sin tener mucha idea de cómo funcionan. El problema es cuando ves que hay metas u objetivos que ves que en el mundo del software libre no se cumplen por culpa del uso de ellas.
El primero de los problemas que ví en este sentido es en la funcionalidad que se tiene en la Hoja de Ruta de MonoDevelop consistente en conseguir que MonoDevelop sea capaz de compilarse a sí mismo ("Make MD self hosting"), algo que, a todas luces, parece importantísimo en mi opinión, pues es una buena muestra de lo que el propio IDE es capaz de hacer. También me pareció muy extraño, en las ocasiones en las que empezaba a conocer este programa, que esta funcionalidad no fuera una de las iniciales del proyecto que se hubieran alcanzado en su principio; aunque al parecer esto no fue así porque la primera versión de MonoDevelop fue un port de SharpDevelop (migración de SystemWindowsForms a GTK#, y de Windows a Linux).
¿Y por qué no puede MonoDevelop compilarse a sí mismo? Pues porque para compilarlo hay que usar las Autotools, y éstas solo pueden invocarse desde la línea de comandos (algo que un IDE precisamente pretende evitar). Existe sin embargo un complemento para MonoDevelop denominado "Autotools Addin" que sirve para la integración de Mono con estas herramientas. Al parecer es éste complemento el que daría la llave para conseguir esta funcionalidad, y de hecho ya la da en algunos casos. Pero al parecer el uso que se hace de las Autotools para la propia compilación de MonoDevelop es tan complejo que la integración de este complemento aún no la soporta (requiere de más trabajo como ya comenta Lluis Sánchez en un mensaje).
La primera vez en la que intenté involucrarme para investigar cómo mejorar esta cuestión (pues sería bastante más cómodo colaborar en MonoDevelop si directamente pudiesemos comprobar que nuestros cambios compilan desde el propio MonoDevelop) acabé escribiendo unas divagaciones en un mensaje que al final acabó sin respuesta (no sé si por la somera estupidez que estaba diciendo...), que voy a citar aquí:
I see. I have been investigating about all these *.in files in MD and
particularly about this one (GettextCatalog.cs.in) and I see that the
only thing that must be generated by the config script file is a
parameter that is a part of a path. Couldn't this parameter be guessed
in execution time instead of pregenerating a source file? I think this
thing is preventing the more intuitive use of an IDE when using this
files because we break the C# syntax completely when adding parameters
like these. I guess that the last consequence of this
is indeed the inability of MD to compile itself (unless the "autotools"
add-in is developed, am I right?), which BTW is a feature requested in
the TODO list of MonoDevelop.
I suppose that all these questions arise to me basically because of my
lack of experience with developing mainly in UNIX/Linux environments,
where I am noticing there is a lot of script culture, use of
command-line tools (make, automake, ...), etc., which I have almost
never used.
Perhaps someone of you could point me to a good tutorial about this
stuff and then I won't bug this list with my dumb questions anymore :)
El tutorial lo he encontrado ya y estoy dando buena cuenta de él. Aunque es bastante engorroso empollarse algo que crees que no tiene futuro, en este caso lo hago porque para luchar contra tu enemigo tienes que conocerlo. Y además ello me permitirá investigar más a fondo ciertos bugs que he encontrado en algunos programas hechos con Mono que impiden usar el idioma predeterminado del sistema cuando se lanzan con make run (instalándolos con make install ya todo se resuelve), algo que también debe influir en la detección del iPod de Banshee porque ocurre algo parecido.
Al menos no soy el único que se pregunta si se podría pasar a otro sistema, como ya lo dicen aquí sugiriendo NAnt. En otros hilos de la lista de Mono se ha sugerido el uso general de .NET PreBuild el cual puede generar archivos de proyecto de NAnt, Visual Studio, MonoDevelop y SharpDevelop.
También es cierto que los chicos de KDE me inspiraron bastante sobre este tema cuando ellos migraron todo su sistema de Autotools a CMake (para su rama inestable) por las mismas razones. Algo que ya los chicos de Gnome se están planteando, pero con ciertas reticencias.
En la primera (y última, de momento) GUADEC en la que estuve, asistí a una charla sobre las Autotools; quizás fue muy técnica y no me dejó ver la idea global, aunque sí me permitió conocer detalles escabrosos de ellas, como por ejemplo la necesidad de poner comentarios que empiezan por "dpl" (me recuerda al odioso REM de los archivos de proceso por lotes de DOS) al final de las líneas, para que no falle por si acaso hemos insertado un espacio accidentalmente antes del retorno de carro. Y es que yo insisto: ¿no es más fácil tener un programa que examine un conjunto de datos sobre configuración/compilación/empaquetado (por ejemplo mediante archivos XML) para que genere todo en lugar de que el programador tenga que escribir scripts a estas alturas? Aún tengo que aprender mucho sobre esto, pero buscando por ahí parece que no soy el único tipo cabreado con esta situación, ya que he encontrado otra alternativa más, el proyecto PMK, que precisamente lo que aboga es por esta separación conceptual.
Actualización 02-MAY-2009: Orgulloso de ver esta conversación en #monodev:
Bueno, yo no es que haya sido "toda la vida" un programador de Windows, sino que en mis pocos años de mi experiencia como programador, los iniciales han sido como usuario de Windows, pero con herramientas de programación poco asociadas a entornos Windows, como Modula2, Hope, Java, C, C++ (los programadores de Windows más curtidos son sin embargo muy expertos en Visual C++, librerías STL, MFC's, etc.).
La cuestión es que, incluso aunque soy un acérrimo usuario de la plataforma .NET para desarrollar, como me gusta Mono tiendo a falimiarizarme con Linux y las autotools son unas de esas herramientas, algo antiguas, que incluso se siguen utilizando en desarrollos más modernos hechos con Mono. Un par de notorios ejemplos pueden ser Banshee y MonoDevelop.
Estas herramientas quizás fueran útiles en el pasado, sobre todo porque no había alternativas. Pero hoy día parecen un parásito feo y horrible que no se acaba de desligar del mundo GNU, a pesar de que hay buenas alternativas ya.
Los inconvenientes que le veo:
- La curva de aprendizaje es exageradamente pronunciada.
- No tienen una forma común de gramática/sintaxis para cada una de las sub-herramientas.
- No son multiplataforma, pues para su ejecución en entornos Windows se requiere de Cygwin.
También puede ocurrir que tampoco tengamos excesivo interés en lidiar con ellas, y de hecho te puedes convertir perfectamente en un colaborador de proyectos libres sin problemas sin tener mucha idea de cómo funcionan. El problema es cuando ves que hay metas u objetivos que ves que en el mundo del software libre no se cumplen por culpa del uso de ellas.
El primero de los problemas que ví en este sentido es en la funcionalidad que se tiene en la Hoja de Ruta de MonoDevelop consistente en conseguir que MonoDevelop sea capaz de compilarse a sí mismo ("Make MD self hosting"), algo que, a todas luces, parece importantísimo en mi opinión, pues es una buena muestra de lo que el propio IDE es capaz de hacer. También me pareció muy extraño, en las ocasiones en las que empezaba a conocer este programa, que esta funcionalidad no fuera una de las iniciales del proyecto que se hubieran alcanzado en su principio; aunque al parecer esto no fue así porque la primera versión de MonoDevelop fue un port de SharpDevelop (migración de SystemWindowsForms a GTK#, y de Windows a Linux).
¿Y por qué no puede MonoDevelop compilarse a sí mismo? Pues porque para compilarlo hay que usar las Autotools, y éstas solo pueden invocarse desde la línea de comandos (algo que un IDE precisamente pretende evitar). Existe sin embargo un complemento para MonoDevelop denominado "Autotools Addin" que sirve para la integración de Mono con estas herramientas. Al parecer es éste complemento el que daría la llave para conseguir esta funcionalidad, y de hecho ya la da en algunos casos. Pero al parecer el uso que se hace de las Autotools para la propia compilación de MonoDevelop es tan complejo que la integración de este complemento aún no la soporta (requiere de más trabajo como ya comenta Lluis Sánchez en un mensaje).
La primera vez en la que intenté involucrarme para investigar cómo mejorar esta cuestión (pues sería bastante más cómodo colaborar en MonoDevelop si directamente pudiesemos comprobar que nuestros cambios compilan desde el propio MonoDevelop) acabé escribiendo unas divagaciones en un mensaje que al final acabó sin respuesta (no sé si por la somera estupidez que estaba diciendo...), que voy a citar aquí:
I see. I have been investigating about all these *.in files in MD and
particularly about this one (GettextCatalog.cs.in) and I see that the
only thing that must be generated by the config script file is a
parameter that is a part of a path. Couldn't this parameter be guessed
in execution time instead of pregenerating a source file? I think this
thing is preventing the more intuitive use of an IDE when using this
files because we break the C# syntax completely when adding parameters
like these. I guess that the last consequence of this
is indeed the inability of MD to compile itself (unless the "autotools"
add-in is developed, am I right?), which BTW is a feature requested in
the TODO list of MonoDevelop.
I suppose that all these questions arise to me basically because of my
lack of experience with developing mainly in UNIX/Linux environments,
where I am noticing there is a lot of script culture, use of
command-line tools (make, automake, ...), etc., which I have almost
never used.
Perhaps someone of you could point me to a good tutorial about this
stuff and then I won't bug this list with my dumb questions anymore :)
El tutorial lo he encontrado ya y estoy dando buena cuenta de él. Aunque es bastante engorroso empollarse algo que crees que no tiene futuro, en este caso lo hago porque para luchar contra tu enemigo tienes que conocerlo. Y además ello me permitirá investigar más a fondo ciertos bugs que he encontrado en algunos programas hechos con Mono que impiden usar el idioma predeterminado del sistema cuando se lanzan con make run (instalándolos con make install ya todo se resuelve), algo que también debe influir en la detección del iPod de Banshee porque ocurre algo parecido.
Al menos no soy el único que se pregunta si se podría pasar a otro sistema, como ya lo dicen aquí sugiriendo NAnt. En otros hilos de la lista de Mono se ha sugerido el uso general de .NET PreBuild el cual puede generar archivos de proyecto de NAnt, Visual Studio, MonoDevelop y SharpDevelop.
También es cierto que los chicos de KDE me inspiraron bastante sobre este tema cuando ellos migraron todo su sistema de Autotools a CMake (para su rama inestable) por las mismas razones. Algo que ya los chicos de Gnome se están planteando, pero con ciertas reticencias.
En la primera (y última, de momento) GUADEC en la que estuve, asistí a una charla sobre las Autotools; quizás fue muy técnica y no me dejó ver la idea global, aunque sí me permitió conocer detalles escabrosos de ellas, como por ejemplo la necesidad de poner comentarios que empiezan por "dpl" (me recuerda al odioso REM de los archivos de proceso por lotes de DOS) al final de las líneas, para que no falle por si acaso hemos insertado un espacio accidentalmente antes del retorno de carro. Y es que yo insisto: ¿no es más fácil tener un programa que examine un conjunto de datos sobre configuración/compilación/empaquetado (por ejemplo mediante archivos XML) para que genere todo en lugar de que el programador tenga que escribir scripts a estas alturas? Aún tengo que aprender mucho sobre esto, pero buscando por ahí parece que no soy el único tipo cabreado con esta situación, ya que he encontrado otra alternativa más, el proyecto PMK, que precisamente lo que aboga es por esta separación conceptual.
Actualización 02-MAY-2009: Orgulloso de ver esta conversación en #monodev:
(11:39:56 AM) vargaz: miguel: it might be better to use cmake to build the class libs.
(11:40:21 AM) miguel: vargaz, this is for the VS crowd
(11:40:29 AM) miguel: Download mono, hit F5, get a full Mono
(11:40:30 AM) vargaz: a makefile generator.
(11:40:38 AM) vargaz: kde uses it to build itself.
(11:40:39 AM) miguel: Yeah, but I need solutions for this
(11:41:00 AM) vargaz: it can generate vsproj files, unit makefiles etc.
(11:41:04 AM) miguel: Ah, cute!
(11:41:24 AM) miguel: Well, if someone wants to replace the current buidl system, I have no problem with that
(11:41:33 AM) miguel: Lemme read on cmake
(11:41:43 AM) miguel: But this is basically layered on our system: it uses our system to produce the vsproj files
(11:44:11 AM) tgiphil: ^ :)
(11:44:17 AM) miguel: My only problem with cmake is that it involves:
(11:44:32 AM) miguel: (a) replacing our system with cmake; (b) using cmake to generate vsproj
(11:44:44 AM) miguel: And I am not really looking forward to do that, not with my copious spare time
(11:45:02 AM) kangaroo: we clearly need to invent a 36-hour day
(11:49:52 AM) robert|j: you guys just have to communicate your ideas and goals properly. the last info I've read on the mailing list on this issue was that jchamber is already working on it.
(11:50:27 AM) miguel: Yes, I have been in contact with chambers
(11:50:40 AM) miguel: But he has been busy with the Windows debugger, so I coordinated this work with him
(11:50:45 AM) miguel: (In this channel btw :-)
(11:56:49 AM) tgiphil: miguel -> will the vsproj files be included in svn; or will we have to run make to get them generated?
(11:58:51 AM) miguel: You need to generate them
(11:59:09 AM) miguel: Since a full bootstrap is going to have some 200 .csproj files
(11:59:31 AM) miguel: I think I want to create a "full" solution for bootstrap purposes, and a "hacking" solution that only includes 2.0
(12:00:13 PM) tgiphil: by "full" you mean, you won't need make tool chain after those files were generated (including the .sln)?
(12:00:18 PM) arnec [~arnec@cpe-66-75-235-18.san.res.rr.com] entered the room.
(12:00:46 PM) kangaroo: HFS+, why do you have to be the SLOWEST FILESYSTEM IN EXISTENC
(12:00:47 PM) robert|j: tgiphil: you'll need to click on a .bat file.
(12:01:08 PM) miguel: Full is a copy of the autoconf/automake process, from beginning to end
(12:01:11 PM) miguel: That will take a long time
(12:01:16 PM) miguel: For hacking, that is not really useful
(12:01:33 PM) miguel: well, actually,I do not know
(12:01:34 PM) miguel: Perhaps it is
(12:01:36 PM) miguel: We will see
(12:02:01 PM) tgiphil: it would be nice not to require cygwin and just build within windows.
(12:03:29 PM) miguel: That is what the solutions do
(12:03:34 PM) miguel: There is no dep on cygwin
(12:04:01 PM) miguel: There are no deps other than Visual Studio, mcs and mono source code checkouts
(12:04:12 PM) tgiphil: awesome... especially for our project.
(12:07:00 PM) vargaz: miguel: I'm working on cmake build files btw.
(12:07:13 PM) vargaz: its a slow process as our configure.in has like 2000 lines.
(12:07:51 PM) eno [~eno@EM114-48-3-242.pool.e-mobile.ne.jp] entered the room.
(12:09:26 PM) miguel: Mhm, so maybe I should drop this
(12:09:38 PM) miguel: No point in doing this work twice
(12:10:07 PM) vargaz: no need to stop, it will be a while before it is finished. and its only for the runtime.
(12:10:41 PM) vargaz: cause of sick of auto*.
(12:10:45 PM) tgiphil: miguel -> how do I kick off creating the .csproj files?
(12:10:50 PM) vargaz: cause I'm sick of auto*.
(12:11:00 PM) miguel: Yeah, sick here too
(12:11:06 PM) kangaroo: +1
(12:11:13 PM) miguel: That is why my small C# projects use plain make
(12:11:45 PM) miguel: When we did gnome-config (the precursor to pkg-config) the goal was to not depend on auto* or use ac macros
(12:12:00 PM) miguel: And somehow people managed to fuck it up by replacing code like:
(12:12:27 PM) miguel: if `pkg-config --modversion 1.2 foo`; then echo ok else echo install-foo-1.2; fi
(12:12:27 PM) miguel: with
(12:12:38 PM) miguel: PKG_CONFIG_CHECK_BLAH(foo, [1.2])
(12:13:04 PM) miguel: Which just increases frustration, specially on OSX or every time automake/autoconf are upgraded
(12:13:37 PM) miguel: Every time I remove that junk, someone goes and plus the automake macro back in
(12:13:44 PM) miguel: autoconf
(12:13:50 PM) miguel: s/plus/plugs/
(12:13:56 PM) kangaroo: We need to shoot m4 in the head
(12:14:02 PM) kangaroo: and anything that uses it
(12:14:13 PM) vargaz: maybe add a comment '# DONT PUT AUTOCONF MACROS HERE!!!!'
(12:14:56 PM) miguel: I should do that
(12:15:01 PM) miguel: The most annoying one was Moonlight
(12:15:07 PM) miguel: Got a few hours to spare, wanted to do some OSX porting
(12:15:14 PM) miguel: The time went straight into fixing autoconf crap
(12:15:40 PM) kangaroo: hrmm? moonlights autoconf is basically find for osx
(12:15:46 PM) kangaroo: s/find/fine/
(12:16:18 PM) miguel: mono$ cat * | grep -c PKG_CHECK
(12:16:18 PM) miguel: 21
(12:16:26 PM) miguel: Not with a clean system
(12:16:36 PM) miguel: Once you have a working setup, it is smooth sailing
(12:16:43 PM) miguel: But it keeps making our builds harder than they should be
(12:17:09 PM) miguel: I'll clean that junk later
(12:17:40 PM) kangaroo: miguel: /usr/X11/share/aclocal/pkg.m4
(12:17:46 PM) kangaroo: you just need to tell OSX's aclocal to look there
(12:17:48 PM) kangaroo: they ship the m4
(12:17:50 PM) kangaroo: (in 10.5)
(12:17:59 PM) kangaroo: OSX's aclocal is just braindead
(12:18:00 PM) miguel: Dude, I know
(12:18:05 PM) miguel: I managed to get it working
(12:18:10 PM) kangaroo: nod
(12:18:21 PM) kangaroo: I should write down my steps to unfuck osx for mono development for everyone
(12:18:32 PM) miguel: Building our shit should not involve setting up ACLOCAL_PATHS just because someone can not be bothered to read:
(12:18:38 PM) miguel: if `pkg-config --modversion FOO`; then fi
(12:19:04 PM) miguel: This is readable, vs PKG_CHECK (a,b,c,d,e,f)
(12:19:07 PM) kangaroo: well.. that wont work out of the box on osx either :)
(12:19:09 PM) miguel: Which you have to lookup anyways
(12:19:12 PM) kangaroo: cause they dont ship pkg-config
(12:19:16 PM) kangaroo: but I know what you mean
(12:19:28 PM) kangaroo: I never understood that of apple
(12:19:34 PM) kangaroo: they ship the .m4 and .pc files, but not pkg-config?
(12:19:45 PM) miguel: We do ship it with Mono
(12:19:57 PM) kangaroo: nod
(12:20:16 PM) kangaroo: I generally end up installing auto* from macports anyways
(12:20:17 PM) miguel: The problem at the core is that aclocal was a poor tool
(12:20:25 PM) miguel: It can not cope with the same file being referenced twice
(12:20:27 PM) kangaroo: since stuff like gtk# and other things in our repo require a newer auto*
Labels: General, Mono, Programacion, SoftwareLibre
# posted by knocte @ 3:35 pm 
Comments:
<< Home
Buenas noches !
Nada, que acabo de pasearme por el weblog y simplemente poner un comentario y un saludo por aquí.
Me ha gustado la entrada de las autotools (confieso que no me gustan nada) :)
Feliz año para tí también.
Nada, que acabo de pasearme por el weblog y simplemente poner un comentario y un saludo por aquí.
Me ha gustado la entrada de las autotools (confieso que no me gustan nada) :)
Feliz año para tí también.
# posted by 
: Sunday, January 07, 2007 9:49:00 pm
: Sunday, January 07, 2007 9:49:00 pm
La verdad es que tienes razón, se dice que emacs, vim autotools son para hombres, yo añadiria hombres aferrados a lo arcaico.
"los hombres valientes usan (emacs, vi.m, los hombres productivos usan un ide".
Post a Comment
"los hombres valientes usan (emacs, vi.m, los hombres productivos usan un ide".
# posted by : Saturday, February 16, 2008 4:18:00 am
: Saturday, February 16, 2008 4:18:00 am << Home
