comment quelqu'un pourrait-il faire un compilateur incrémental ac # comme Java?

Question

Il y a des années quelqu'un m'a demandé pourquoi c# ne pas permettre incrémentielle de compilation Java. El Skeet dit que c'est à voir avec Java à la sortie .les fichiers de classe plutôt que des assemblées.

Maintenant que sa 2011 et groovy, des choses comme le compilateur Mono-as-a-service ont été libérés, ce qui devrait être fait pour faire des sauvegardes incrémentales compilateur pour c#?

edit: pour tout le monde cogner sur la façon dont ce n'est pas un problème, voici une citation de Jon Skeet du thread, j'ai lié à :

Suggérez-vous que vous ne jamais vous retrouver en attente pour un build? Même 15 secondes? Si une construction prend 15 secondes et que vous voulez construire 20 fois dans d'une heure (dont je n'ai certainement TDD) cela signifie que je perds 5 minutes. Prenant une pause de 5 minutes est une chose - c'est une bonne façon de détente, etc - mais maintenues pendant 15 secondes 20 fois peut être très frustrant. Il n'est pas assez long pour faire quelque chose d'utile (autres que peut-être boire un verre), mais c'est assez long à irriter.

Je soupçonne deux facteurs contribuent le niveau de désagrément que j'ai une sensation qui les autres ne semblent pas: 1) TDD vraiment s'appuie sur une rotation plus rapide 2) Lorsque l'on travaille avec Java dans Eclipse, de tels retards sont très rares

Answer 1

Si elle n'a pas été fait, alors il n'y a qu'une seule raison à cela: les efforts à faire sont plus élevés que les avantages possibles.

Microsoft ne sera certainement pas le faire parce que les coûts sont trop élevés: .net code de vie dans les assemblées et personne ne pourra le changer. Et oui, les assemblées, les empêcher de classe par classe compilation incrémentielle. Personne ne va cesser d'utiliser des assemblages.

Et voici ma réponse pourquoi personne n'en a besoin. Vous pouvez distribuer vos classes qui constituent projet unique parmi plusieurs assemblées et compiler un par un. Il est effectivement compilation incrémentielle, mais pas comme la plus fine de la classe par classe compilation incrémentielle. Et quand votre architecture est bien conçu au niveau de l'assemblée compilation incrémentielle est suffisant.

Edit: Ok, j'ai téléchargé Mono compilateur C# afin de prendre un coup d'oeil, il est possible de faire incrémental. Je pense que c'est pas très dur. Fondamentalement, il n'étapes suivantes: 1) Analyser les fichiers 2) Compiler 3) Créer de l'assemblée. Vous pourrais accrocher quelque part après les types sont compilées et de l'enregistrer ensuite dans une sorte de fichiers intermédiaires. Puis recompilez seulement changé ceux. Il est donc possible, mais on dirait que ce n'est pas de haute priorité pour l'équipe de Mono.

Edit 2: j'ai trouvé ce sujet intéressant où les gens discuter de compilation Incrémentielle pour Mono compilateur C#. Il est plutôt vieux, mais la clé de l'explication pourrait être en cours de validité:

Lexing et l'analyse sont normalement très rapide et ne dépendent de la taille de le code pour être analysée. Sémantique l'analyse est normalement le plus de temps consommer de l'étape de chargement référencés assemblées et tamisage autour de l'énorme des métadonnées pour résoudre les symboles et les types de est vraiment la viande du compilateur, aussi, de nouvelles "compilé" code "ajouté" à ces métadonnées/AST ce que augmente la complexité de la résolution de les symboles au fil du temps. Les émissions de code est fait en mémoire de sorte qu'il est rapide. La sauvegarde sur disque est lent, mais cela dépend de émis de la taille du code.

Progressive de la compilation, la mise en cache de la les métadonnées, serait de faire tout très rapide, car normalement très peu serait modifié à partir d'une compilation à l' d'autres. Mais cmg aurait à invalider une partie seulement de la les métadonnées/AST, ce qu' il n'a pas été construit pour.

Edit 3: compilateur C# a /incremental option dans v1.0 et v1.1, mais il a été supprimé:

L' /incrémentielle drapeau trouvé dans la 1.0 et 1.1 version du compilateur C# est maintenant obsolète.

Edit 4: Miguel de Icaza donne la réponse (1, 2) pourquoi Mono Compilateur ne sera pas incrémental:

Il y a beaucoup, beaucoup plus d'endroits où CMG est tout simplement pas conçu pour fonctionner sur edit-et-continuer le scénario.

Si quelqu'un veut en faire leur sujet de thèse, qui est très bien avec moi, mais le nombre de changements sont trop grand dans de trop nombreux domaines. Je n'ai pas même voulez déranger l'énumération d'eux.

La raison je n'ai pas la liste des choses est parce qu'ils seront partout dans le compilateur. Suis sûr que vous allez courir dans dès que vous les essayer ;-)

Donc, il considère qu'il est une tâche plus énorme que pour un homme et de sa thèse. Et Mono a beaucoup plus de circulation et de tâches concrètes.