c# - libros - compilador en java paso a paso
¿Cómo podría alguien hacer un compilador incremental ac#como Java? (1)
Hace años alguien preguntó por qué c # no permite una compilación incremental como Java . El Skeet dijo que tiene que ver con Java que genera archivos .class en lugar de ensamblados.
Ahora que se han lanzado 2011 y cosas geniales como el compilador como servicio de Mono, ¿qué habría que hacer para hacer un compilador incremental para c #?
edit: para todos los que hablan sobre cómo esto no es un problema, aquí hay una cita de Jon Skeet del hilo al que he vinculado:
¿Estás sugiriendo que nunca te encontrarás a la espera de una construcción? Incluso 15 segundos? Si una compilación demora 15 segundos y desea compilar 20 veces en una hora (lo que ciertamente hago con TDD), significa que estoy perdiendo 5 minutos. Tomar un descanso de 5 minutos es una cosa, es una buena manera de relajarse, etc., pero esperar 15 segundos puede ser muy frustrante. No es lo suficientemente largo como para hacer algo útil (aparte de tomar una bebida), pero es lo suficientemente largo como para irritar.
Sospecho que dos factores contribuyen al nivel de molestia que siento que otros aparentemente no: 1) TDD realmente confía en un cambio más rápido 2) Cuando se trabaja con Java en Eclipse, estos retrasos son muy raros
Si no se hizo, entonces solo hay una razón para ello: los esfuerzos para hacerlo son mayores que los posibles beneficios.
Microsoft definitivamente no lo hará porque los costos son demasiado altos: el código .net vive en ensamblajes y nadie lo cambiará. Y sí, los ensamblajes impiden la compilación incremental clase por clase. Nadie dejará de usar los montajes.
Y aquí está mi respuesta por qué nadie lo necesita. Puede distribuir sus clases que constituyen un solo proyecto entre varios ensamblajes y compilarlos uno por uno. En realidad, es una compilación incremental, pero no tan detallada como la compilación incremental clase por clase. Y cuando su arquitectura está correctamente diseñada, la compilación incremental a nivel de ensamblaje es suficiente.
Edit : De acuerdo, descargué el compilador Mono C # para echar un vistazo, es posible hacerlo incremental. Creo que no es muy difícil. Básicamente realiza los siguientes pasos: 1) Analizar archivos 2) Compilar 3) Crear ensamblaje. Puede enganchar en algún lugar después de compilar los tipos y guardarlos en algún tipo de archivos intermedios. Luego recompile solo los modificados. Así que es posible, pero parece que no es un problema de alta prioridad para el equipo Mono.
Edición 2 : Encontré este interesante hilo en el que la gente discute Compilación incremental para el compilador Mono C #. Es bastante antiguo, pero la explicación clave podría seguir siendo válida:
El procesamiento y el análisis normalmente son muy rápidos y solo dependen del tamaño del código que se analiza. El análisis semántico es normalmente el paso más lento, ya que cargar ensamblajes de referencia y examinar los metadatos enormes para resolver símbolos y tipos es realmente la carne del compilador, además, el nuevo código "compilado" se "anexa" a este metadato / AST, lo que aumenta La complejidad de resolver símbolos a lo largo del tiempo. La emisión de código se realiza primero en la memoria para que sea rápido. Guardar en disco es lento pero depende del tamaño del código emitido.
Para la compilación incremental, el almacenamiento en caché de los metadatos haría que todo fuera muy rápido, ya que normalmente se cambiaría muy poco de una compilación a otra. Pero gmcs tendría que invalidar solo una parte de los metadatos / AST, para lo que no fue creado .
Edición 3 : el compilador de C # tenía /incremental opción /incremental en v1.0 y v1.1, pero se removed :
La marca / incremental encontrada en las versiones 1.0 y 1.1 del compilador de C # ahora se considera obsoleta.
Edición 4 : Miguel de Icaza da una respuesta clara ( 1 , 2 ) de por qué Mono Compiler no será incremental:
Hay muchos, muchos más lugares donde GMCS simplemente no fue diseñado para funcionar en un escenario de edición y continuación.
Si alguien quiere hacer de esto su tema de tesis, eso está bien para mí, pero la cantidad de cambios es demasiado grande en muchas áreas. Ni siquiera quiero molestar en enumerarlos.
La razón por la que no mencioné las cosas es porque estarán en todas partes en el compilador. Estoy seguro de que te encontrarás con ellos tan pronto como los pruebes ;-)
Así que él considera que es una tarea más difícil que para la tesis de un hombre. Y Mono tiene tareas mucho más destacadas y reales.