Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.

Wednesday, January 17, 2007

 

Microsoft miente acerca de sus estándares

Al parecer Microsoft quiere seguir el camino del formato OpenDocument, el cual se ha convertido en el primer estándar abierto ISO que define la especificación formal para un documento de texto elaborado por un programa ofimático. Este contenido se guarda en un subformato XML comprimido, y, como no podía ser menos, Microsoft acude raudo y veloz a nombrar a su estándar "OpenXML", como queriendo dar a entender a la gente poco informada de que su estándar será el único que sea XML y sea abierto. ¿Dónde está especificado en el nombre que es un estándar para documentos ofimáticos? Con ese nombre podría servir para cualquier cosa.

Pero en fin, eso no es lo grave del asunto. El problema es que, para empezar, en sus programas ofimáticos no dan soporte de OpenDocument. En realidad, no podemos quejarnos de eso, ellos harán lo que quieran con sus programas, aunque en este caso parece una maniobra de boicot para abrir más puertas a su venidero estándar.

Para continuar, quieren que su estándar OpenXML (ya bendecido por el comité ECMA) se convierta también un estándar abierto ISO, al igual que ha ocurrido con OpenDocument. Pero hay una diferencia enorme entre los dos casos, pues en el caso de OpenXML, estamos ante un estándar que ni siquiera se le puede calificiar como tal, pues, como ya ha denunciado un desarrollador (que debe estar trabajando para lograr la interoperabilidad de OpenXML en OpenOffice.org), hay partes del documento que no son públicas en absoluto. Es decir, que no es un estándar abierto.

Algunos ejemplos para demostrar estas afirmaciones, extraídos del enlace ya facilitado al blog del desarrollador, son las partes del estándar en las que se obliga a la aplicación que lo implemente a imitar el comportamiento de aplicaciones antiguas de Microsoft. Esto obliga a que los desarrolladores tengan que utilizar técnicas de ingeniería inversa para "desvelar" estas partes ocultas del estándar y poder implementarlas; algo que, a todas luces, no es el procedimiento normal por el cual se pretende publicar un estándar para que un tercero pueda implementarlo.

Los casos que más me han llamado la atención han sido los que se alude a una versión de Word para Macintosh de hace 14 años, y otro incluso en el que se pide emular el comportamiento de la aplicación WordPerfect (que no es ni siquiera de Microsoft) de hace 16 años.

EstandaresAbiertos.com también se ha hecho eco de este despropósito. Y en su informe revelan algunas razones más por las que creen que el estándar de Microsoft no debería llegar a convertirse en ISO. Citaré las que considero más importantes (el resto quizás son bastante discutibles, todo hay que decirlo; al menos, como argumentos en contra de su publicación como estándar, ya que quizás sí son argumentos buenos a la hora de elegir entre un estándar y otro), algunas de ellas por aludir al caso que ya he explicado de ocultación de información:

1. Más de 7000 páginas de especificación hacen muy inviables implementaciones alternativas completas e imposibilitan poder ser 100% compatibles con la especificación (y más cuando ISO 26300 cubre la misma funcionalidad con solo 600 páginas). [Actualización (1): argumento tachado, a consecuencia de los buenos argumentos de Miguel de Icaza en su entrada sobre el tema.] Por otra parte y además, la especificación publicada ni siquiera es completa, ya que en múltiples puntos referencia a información que no es pública y que es conocida solamente por Microsoft.
(...)
4. No existe garantía legal de no infracción de patentes y el dueño del formato en su licencia no ofrece garantía alguna de que la especificación ECMA-376 se pueda implementar al completo en ninguna aplicación competidora sin ser demandado en los mercados donde son legales.
5. El formato, al no ser 100% XML, ata a plataformas concretas de un único fabricante mediante el uso de excepciones y codificaciones binarias exclusivas de sus sistemas operativos.
6. ECMA-376 no ha sido depurado en el proceso de estandarización y codifica expresamente y en detalle errores obvios conocidos y no corregidos que obligan a que las aplicaciones competidoras los tengan que implementar innecesaria y artificiosamente.
7. Codificación críptica propia de un volcado de memoria que es difícimente inteligible para un humano y que prácticamente imposibilita la conversión de los documentos a formatos web como XHTML.
(...)
10. Y, finalmente, en cuanto al procedimiento de estandarización seguido, el objetivo oficial declarado por el Comité Técnico de estandarización de ECMA habla por sí mismo sobre la nula apertura a la competencia que ha seguido dicho proceso. Textualmente tal objetivo ha sido: "producir un estándar (...) que sea completamente compatible con los Formatos Office Open XML, remitidos por Microsoft".

¿Se dará cuenta la gente de la desvergüenza de esta compañía? O casi más importante, ¿se darán cuenta los gobiernos de las tácticas monopolísticas ilegales que lleva a cabo?

En fin, yo lo único que sé a ciencia cierta de todo esto es que la organización ISO perdería, al menos por mi parte, ese "prestigio" subjetivo que les adjudicaba hasta ahora. Y eso me hará dudar también de ahora en adelante de sus estándares ya aprobados hasta el momento.

Pobres ingenieros de Novell... Cualquiera querría formar parte del equipo que le vaya a tocar implementar esta especificación endemoniada...

Actualización 31-ENE-2007: Miguel de Icaza publica una entrada sobre este tema en la que se posiciona desde un punto de vista bastante imparcial, pues critica a Microsoft pero también critica algunos puntos del estándar ODF que cometen los mismos errores.

Labels: , ,


Sunday, January 14, 2007

 

Una de gadgets

Los primeros gadgets que puedo decir que tuve fueron mis primeros móviles Nokia (si se le pueden llamar gadgets). Empecé con un 6110, después un 6210 (del cual fui poseedor de dos unidades, pues la primera me la robaron), 6310 (éste no lo compré, me lo dieron como recambio a mi último 6210 que tenía infinitos problemas de cobertura; ¡un olé para Nokia!) y ahora tengo un 7210 (el cual adquirí básicamente por su tamaño y por tener radio integrada). Los Nokia siempre me han parecido mucho más bonitos e intuitivos de manejar.

Otros gadgets que empecé a comprarme fueron los auto-radios para coche con posibilidad de lectura de CD's con MP3. Mi primera adquisición fue la Kenwood MP6090R (imagen), ¡la primera Kenwood con lectura MP3! Y fue una buena compra; recuerdo que aproveché un viajecito a Barcelona para comprármela en una de las tiendas del puerto de esta ciudad, pues allí la tenían mucho más barata que en cualquier otro sitio. Después de esa radio ahora tengo un modelo sucesor (aunque ya se ha quedado algo antiguo también, unos 3 añitos): la KDC-PSW9521. No me he comprado más modelos sucesores por dos razones:

1) No veía novedades enormes como para cambiar.
2) No tenía a nadie que le interesase tener mi modelo antiguo, y claro, jeje, no me gusta tirar las cosas a la basura.

Con respecto a la primera razón, lo que ocurre es que yo me muevo por cambios de "paradigma" (¡como en la programación!). Si me dicen que un nuevo modelo de Kenwood ahora es capaz de leer MP3 en soporte DVD+RW (además de CD-RW como el que ya tengo) pues es posible que me hubiera cambiado. Porque aunque en un CD ahora quepan 180 canciones en lugar de 18, sigues teniendo que cambiar de CD continuamente y es un coñazo. Estuve pensando en comprarme un cargador de 10 CDs con MP3, pero en 10 discos tampoco me cabe mi colección entera de música así que al final habría estado teniendo que meter mano al cargador en más de una ocasión (además no he encontrado cargadores de DVD-MP3).

Así que lo he hecho: he cambiado de paradigma, pero sin tirar mi radio a la basura. ¿Cómo? Comprando un iPod de 60GB, en el que me cabe toda mi música de sobra, y el cual puedo conectar a la radio del coche mediante un cable llamado KCA-iP500. Además así me deshago de una vez de los discos ópticos, que siempre me dan problemas porque se rallan (su vida útil es pequeñísima) y además tienen canon (el de los ladrones).


Siempre había pensado, tal como opinaba también mi amigo Paco en una conversación que tuvimos un día, que este tipo de cosas (música MP3 y móviles) convergerían en una. Y con lo del iPod lo ví todavía más claro: el cacharro es lo más parecido a un móvil, pero claro, ponte a buscar tú ahora un móvil con 60GB de almacenamiento...

Además, últimamente los teléfonos móviles (concretamente los que sacaba Nokia, ya que yo soy un obcecado de la vida) no me daban apenas cosas que me interesarán mucho más de las que ya tiene mi querido 7210 (que ya debe tener unos dos o tres años) así que no me he comprado ningún otro. Estuve tentado de comprarme un 6230i, lo que podía llamarse la siguiente generación al mío pero con cámara y con mejoras a sus predecesores 7250, 7250i y 6230, pero la cámara seguía dejando mucho que desear con respecto a las cámaras digitales normales y el resto de cosas no me aportaban mucho para la pasta que costaba (interesante el tema de poder grabar conversaciones... pero por sólo eso no merecía la pena).
Hasta que de repente Nokia ha sacado sus "NSeries", los cuales son unos teléfonos bastante vistosos (aunque un poco grandes) y con muuuchas funcionalidades. Estudiando bien sus especificaciones técnicas pude comprobar que las cosas que más me llamaban la atención eran sus cámaras ahora nada despreciables (por tener óptica Carl Zeiss, zoom óptico y flash) y el soporte WiFi (bueno, parece una frikada acceder a internet a través del móvil, pero básicamente lo que más me gusta de esto es poder interconectar móvil y ordenador sin usar tecnologías guarras como infrarrojos o bluetooth). Y claro, si quería tener ambas cosas, por lo que pude averiguar, mi única opción era el Nokia N93 (el más caro de la gama por el momento), y estuve a punto de comprarlo pero al final tenía clavada la espinita de siempre: que le faltaban cosas. Entre ellas el GPS y una capacidad de memoria (¿disco duro?) con la que pudiera codearse con el iPod (como ya he comentado más arriba). Lo primero lo veía más alcanzable a corto plazo pues incluso ya existía un accesorio de GPS bluetooth que podría interactuar con este y otros modelos de Nokia, y así utilizarlo de manera factible con un software como el de Route66.

Pero ahora resulta que estas dos funcionalidades que yo consideraba "espinitas" se han propuesto enterrarlas por completo, pues en el primer trimestre de este año aparece el Nokia N95, el cual no es más que un Nokia N93 mejorado y ¡con GPS integrado! Y además Apple también se une a la fiesta anunciando el iPhone, del cual no me he podido empapar mucho aún de sus características, pero bien podría decirse que es un Nokia N95 pero con un disco duro algo decente (creo que 10GB) para de esta manera intentar igualarse un poquito más al iPod.

Aquí un vídeo impresionante sobre el tipo de cosas que es capaz de hacer el iPhone (a destacar su interfaz táctil, su detección de rotación, su interfaz para la búsqueda de álbumes musicales...):


Enlace al vídeo por si no lo ves embebido.

En fin, como al parecer al iPhone le queda aún un año por llegar a España y sigue teniendo una capacidad algo baja con respecto a mi iPod (el cual estoy pensando si sustituir por uno de 80 GB o esperarme al de 100, jeje), tengo decidido que me voy a comprar un Nokia N95, sobre todo por la cámara, que digo yo que ya me merezco una.

Así que para terminar la entrada, otro vídeo, pero del Nokia N95:


Enlace al vídeo por si no lo ves embebido.

PD: Ya se me olvidaba incluir otro gadget que me ha dejado con la boca abierta: unos altavoces que adquieren su fuente de sonido a través de la red eléctrica.

PD II: Como recordatorio para mí mismo, voy a dejar aquí unos enlaces que tengo que mirar, relativos a la interoperabilidad de los móviles Nokia usando Linux: Linux+Gadgets, Linux+Nokia. (Para interactuar con el iPod ya tenemos Banshee ;) Y aquí más enlaces sobre gadgets que usan el propio Linux como core.

Actualización 14-ENE-2007: Se me había olvidado comentar que me parece patético que Nokia no converja sus NSeries con sus PDA's modelos 770 y 800. Lo bueno que tienen éstas es que corren sobre Maemo, un sistema operativo que parece que está rompiendo moldes en la comunidad open source (pues se le puede instalar Mono). Lo malo que tienen es que no son móviles, así que es un aparatejo más que llevar en el bolsillo... (Es una pena que el Nokia N95 lleve Symbian en lugar de Maemo.)

Actualización 04-ABR-2007: La espera es larga pero parece que merecerá la pena. Aquí hay alguien ya bastante contento con el GPS de su Nokia N95, del cual ha capturado un vídeo de muestra en funcionamiento con el coche:




Y aquí:1,2,3 por fin sitios donde se puede comprar...

Actualización 18-ABR-2007: Vaya, parece que los gadgets con Linux van adquiriendo protagonismo. Aquí se hace un resumen bastante bueno sobre uno. Y aquí Nukeador nos habla de una útil herramienta (para Linux) de conversión de formatos para móviles.

Actualización 22-ABR-2007: ¡Cuidadín con las operadoras que capan el Nokia N95!

Actualización 17-JUL-2007: Voy a tener que replantearme lo del iPhone después de ver esto (libreria .NET para acceder al sistema de ficheros del iPhone).

Actualización 17-ABR-2007: Estoy descubriendo herramientas interesantes para gestionar tu móvil desde Linux, como Wammu o KMobileTools, ambas instalables via 1click.

Labels: , ,


Wednesday, January 10, 2007

 

OpenSUSE 10.2: Im-presionante

Poco más puedo decir de esta nueva versión de OpenSUSE, la cual me han enviado la gente de Novell por correo ordinario como agradecimiento a haberla testeado (la selección de agraciados fue extraída de una simple query a su bugzilla), todo un detallazo. Es la primera vez en la que realmente me siento comodísimo trabajando con Linux. A destacar los siguientes puntos:

- Da gusto la restauración de la sesión de Firefox 2.0.
- Han mejorado bastante las transparencias del terminal de Gnome (ver captura).
- No sé qué tiene la tipografía predeterminada, que me parece súper agradable a la vista. Nada que ver con la de las anteriores versiones o la de otras distros (ver captura).
- No sé cómo lo han conseguido, pero tengo XGL (aka Efectos3D) funcionando con mi tarjeta gráfica cutrilla del portátil (la cual pensaba que no tendría apenas aceleración 3D, vale que va un pelín lento pero funciona), y además sin necesidad de escribir un sólo comando en la consola para activarlo.
- Banshee de serie con el motor de Helix para que pueda reproducir MP3 sin necesidad de códecs o repositorios non-free externos (aunque claro, he tardado dos milésimas de segundo en instalarme mis paquetitos de GStreamer para trastear un poco).



Cosas menos destacables:
- Han cambiado el menú predeterminado de Gnome y me está costando un poco hacerme al nuevo.
- El selector de zonas de escritorio parece más "transparente" y no se distinguen bien las zonas que no están en uso.
- Extraño que la configuración predeterminada para cuando se acaba la batería del portátil sea APAGAR en lugar de HIBERNAR, porque puede provocar pérdida de datos. Ya lo he configurado bien en el mío.
- La traducción de la distro aún deja un poco que desear. Si siempre me he quejado de que esté en Spanglish, al menos ahora está algo menos (diría que han pasado de un 60-40 a un 80-20, donde el primer porcentaje es el español). [Ya sabemos que no lo hacen adrede, pero lo de dejarse cadenas sin traducir debería ser un punto más importante en la fase de QA.]
- Curioso que a pesar de haber desinstalado Beagle (lo sé, es un software muy interesante y seguro que está muy bien hecho, sobre todo porque está hecho en Mono ;) pero yo no lo uso y además creo que provoca que la gente sea aún más desordenada con sus datos de lo que ya lo era antes), insiste en quedarse un icono de un perrito muy majo en la esquina inferior derecha de mi Firefox.
- Ha mejorado muchísimo la gestión de instalación/desinstalación/actualización de software, tanto por YAST (en el que ya no tenemos más congelaciones extrañas de la interfaz) como por ZMD.

Notas adicionales:
- Aquí un buen how-to para configurar aspectos relativos a lado "servidor" de la distro, pero sin bajar a nivel bajo (a lo sumo tendremos que lanzar un par de comandos por consola, nada de editar ficheros de configuración ni ninguna de esas cosas de las que huyen los windowseros o sysadmin vaguetes ;). [YAST powered]
- Sensacional el plugin del NetworkManager, para el cual he encontrado un repositorio del BuildService de OpenSUSE, que me permite conectarme a puntos VPN de tipo PPTP (sí, esos administrados por un servidor Windows, que suponen un agujero de seguridad acojonante pues no están a la última como otras piezas de software más serias del estilo de OpenVPN, pero bueno...).

Actualización 14-ENE-2007: Adjunto un vídeo muy chulo de Novell como promoción de SUSE Linux:


Enlace al vídeo por si no lo ves embebido.

Actualización 14-FEB-2007: Muy interesante el consejo de Wade Berrier (el encargado, dentro del equipo del Proyecto Mono, de la empaquetación de versiones y demás) acerca de cómo activar la alternación de sesión gráfica en caliente, sin cerrar la actual, de OpenSUSE; la cual se consigue a través de un botón del salva-pantallas, después de aplicar este comando:

gconftool-2 --set --type bool /apps/gnome-screensaver/user_switch_enabled true

A ver si lo ponen pronto configurable mediante interfaz gráfica bonita...

Actualización 10-NOV-2007: Bueno, ya he actualizado casi todos mis sistemas a la reciente salida del horno OpenSUSE 10.3 y ha mejorado muchísimo. Aquí una lista de cosas:

Esta vez he estado muy ocupado con el trabajo y no he podido reportar nada ni ayudar a la comunidad, por lo que no me ha tocado ninguna caja esta vez :(

Labels: ,


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:


(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: , , ,


This page is powered by Blogger. Isn't yours?

Categories

RSS of the category Gnome
RSS of the category Mono
RSS of the category C#
RSS of the category Programming
RSS of the category Mozilla
RSS of the category Web Development
RSS of the category Security
RSS of the category Open Source
RSS of the category Engineering
RSS of the category Misc
RSS of the category Politics

Contact with me:
aaragonesNOSPAMes@gnNOSPAMome.org

Archive
My Photo
Name:
Location: London, United Kingdom
Follow me on Twitter