eclipse-plugin incremental-build incremental-linking incremental-compiler

eclipse plugin - ¿Cuál es el mejor enfoque para la compilación incremental al construir un DSL usando Eclipse?



eclipse-plugin incremental-build (1)

Esta es una pregunta interesante y que no tiene una solución simple. Trataré de describir una posible solución y también describiré con un poco más de detalle cómo JDT logra la compilación incremental.

Primero, un poco sobre JDT:

Sí, JDT lee los archivos de clase para algunos de sus datos, pero solo para bibliotecas que no tienen código fuente. Y esta información realmente solo se usa para la asistencia de edición (asistencia de contenido, navegación, etc.).

JDT calcula la compilación incremental al hacer un seguimiento de las dependencias entre las unidades de compilación a medida que se compilan. Esta información de estado se almacena en el disco y se recupera y actualiza después de cada compilación.

Como un ejemplo más completo, digamos que después de una construcción completa, JDT determina que A.java depende de B.java, que depende de C.java.

Si hay un cambio estructural en C.java (un cambio estructural es un cambio que puede afectar los archivos externos (por ejemplo, agregar / eliminar un campo o método no privado)), entonces se recompilará B.java. A.java no se volverá a compilar ya que no hubo cambios estructurales en B.java.

Después de esta pequeña aclaración sobre cómo funciona JDT, aquí hay algunas posibles respuestas a sus preguntas:

  1. Sí. Esto debe hacerse a través de objetos globales accesibles de forma estática. JDT hace esto a través de los objetos JavaCore y JavaModelManager. Si no desea utilizar singletons globales, puede acceder a su tienda de tipos disponible a través de la instancia del activador de Bundle de su complemento. El proyecto e4 permite la inyección de dependencias, que probablemente sea aún mejor (pero en realidad no forma parte de las API centrales de Eclipse).
  2. Creo que la mejor opción es persistir en la información del sistema de archivos. La única manera real de determinar las dependencias de compilación incrementales es hacer una compilación completa, por lo que debe persistir la información en algún lugar. De nuevo, así es como lo hace JDT. La información se almacena en el directorio '' .metadata sus .metadata trabajo en algún lugar del complemento org.eclipse.core.resources. Puede echar un vistazo a la clase org.eclipse.jdt.internal.core.builder.State para ver la implementación.

Por lo tanto, esta puede no ser la respuesta que está buscando, pero creo que esta es la forma más prometedora de abordar su problema.

Como lo sugiere la documentación de Eclipse, tengo un org.eclipse.core.resources.IncrementalProjectBuilder que compila cada archivo fuente y, por separado, también tengo un org.eclipse.ui.editors.text.TextEditor que puede editar cada archivo fuente. Cada archivo fuente se compila en su propia unidad de compilación, pero puede hacer referencia a tipos de otros archivos fuente (ya compilados).

Dos tareas para las que esto es importante son:

  1. Compilación (para asegurarse de que los tipos que estamos usando realmente existen)
  2. Autocompletar (para buscar el tipo para que podamos ver qué propiedades / métodos hay en él)

Para lograr esto, quiero almacenar una representación de todos los tipos compilados en la memoria (a los que se hace referencia a continuación como mi "tipo de tienda").

Mi pregunta es doble:

  1. La tarea uno anterior la realiza el constructor y la tarea dos el editor. Para que ambos tengan acceso a esta tienda de tipos, ¿debo crear una tienda estática en alguna parte a la que ambos puedan tener acceso, o Eclipse ofrece una manera más ordenada de lidiar con este problema? Tenga en cuenta que es eclipse, no yo, lo que instancia a los constructores y editores cuando se necesitan.

  2. Al abrir Eclipse, no quiero tener que reconstruir todo el proyecto solo para poder volver a llenar mi tienda de tipos. Mi mejor solución hasta el momento es conservar estos datos en algún lugar y luego volver a llenar mi tienda desde allí (tal vez al abrir el proyecto). ¿Es así como otros compiladores incrementales suelen hacer esto? Creo que el enfoque de Java es usar un analizador especial que extraiga de manera eficiente esta información de los archivos de la clase.

Cualquier idea sería muy apreciada. Este es mi primer DSL.