L'erreur que je reçois est comme ceci:
J'ai besoin de savoir ce que cette erreur je rencontre signifie vraiment, et si possible, comment résoudre et résoudre ces problèmes, en particulier lorsque les faits indiqués dans le message d'erreur ne sont pas corrects (les unités font en fait référence à d'autres unités de autres packages valides).
De tels problèmes impliquent des dépendances de paquets. J'ai un problème intéressant avec une série de trois types de conception et trois packages d'exécution liés comme suit:
Quel est le plus étrange à ce sujet est que chaque fois que je nettoie et reconstruisez, je reçois un nom d'unité différent dans l'erreur. (Montré ci-dessus comme unité Xbat fait référence à l'unité Qbee).
L'autre chose étrange est que cela fait référence aux unités situées dans une dépendance de haut niveau et faisant partie d'un paquet déjà construit.
étapes;
Depuis que je doute que tout le monde puisse me dire comment résoudre ce problème, je cherche les étapes à suivre pour résoudre un problème de dépendance complexe dans un package. La signification littérale de l'erreur ci-dessus suggère par exemple que je devrais avoir un message correspondant sur une unité liée implicite que je n'ai pas. J'ai ajouté toutes les unités implicitement utilisées aux packages de base A, et B, de sorte qu'aucun avertissement implicite ne soit fait.
Ma prochaine idée était de séparer les dossiers de sortie de la DCU pour chaque package afin d'empêcher que les sorties DCU d'un de l'un de confondre le compilateur. Maintenant, je ne peux même pas construire les paquets.
update 2 Le problème sous-jacent de base n'est pas résolu en activant ou en désactivant la reconstruction explicite. Au lieu d'obtenir cette erreur, je reçois des problèmes d'emballage d'exécution / de conception gênants, ce qui entraîne un ensemble de packages, qui ne peut pas être chargé en même temps. (Impossible de charger l'emballage FOO car il contient une barre d'unité qui est également dans la batte d'emballage. Voulez-vous essayer de charger ce package la prochaine fois qu'un projet est chargé?). [Erreur fatale DCC] MyUnit.PAS (244): E2411 Unité Xbat dans l'emballage B_DSGN fait référence à l'unité Qbee qui n'est trouvée dans aucun package. Les unités emballées doivent se référer uniquement aux unités emballées
Reconstruit explicite et Reconstructible selon vos besoins Options. J'ai constaté que cette erreur est liée à «reconstruire si nécessaire» allumé. Lorsqu'il est éteint, les packages échouent avec d'autres erreurs qui sont davantage au point. Je trouve étrange que le compilateur émet des erreurs étranges qui peuvent être désactivées en désactivant reconstruisant au besoin . Des idées ce qui se passe?
4 Réponses :
Je soupçonne que c'est un bug de compilateur obscur.
Le projet que j'ai vécu dans l'entrée avait au moins 4 niveaux de packages d'exécution dépendants:
packagea <- paquetb <- Packagec <- emballé
Unité E2411 '% s' dans le paquet emballé fait référence à l'unité '% s' qui n'est pas trouvé dans n'importe quel paquet. Les unités emballées ne doivent se référer qu'aux unités emballées.
La seule solution que j'ai trouvée qui a fonctionné était de créer des packages A, B et C Navigation sans construire (c.-à-d. Construire explicite) et utiliser dépendances du projet pour appliquer la commande de construction à la place. Je devais faire tous les trois jamais construits ou j'aurais
E2220 Paquet JAMAIS Build '% S' nécessite un package toujours de construction '% s'
Je sais que ce n'est probablement pas la réponse que vous recherchiez mais là-bas.
BTW, cela m'est arrivé à Delphi 2009.
Cela correspond à mon expérience. J'aimerais pouvoir produire une instance reproductible portable de ce bogue, je pourrais donc le signaler à QC.
Je trouve le docwiki très utile ici: Jamais construit signifie que l'interface est corrigée, tout en construisant toujours signifie qu'il est toujours en développement:
C'est ce que disent les docs. Ce que je pense que cela signifie vraiment, c'est que "le système de gestion de la dépendance à Delphi est subtilement brisé et a besoin de réparer, mais jusqu'à ce que nous réparions, vous pouvez la désactiver lorsque vous avez terminé le développement sur un projet et que nous ferons moins de reconstruction complète inutile lorsque notre Le système de dépendance échoue dans une mode coincée ».
Merci Kenneth. J'ai couru dans le problème d'échantillon dans Delphi Xe2 et votre suggestion a fonctionné.
Mince. Cette solution ne fonctionnera pas pour moi, car le package A contient des utilitaires souvent utilisés / mis à jour / amélioré. Le forfait A doit toujours compiler! Et tout le monde dépend du paquet A.
Il est assez simple: si une unité en C se réfère à une unité non dans aucun paquet mentionné par le package C, cette unité doit être incluse dans C, ou que l'emballage dans lequel il se trouve peut être trouvé doit être référencé par C. Si nécessaire, mettez l'appareil dans un paquet à part entière.
où vous mettez quelle unité dépend des dépendances. Il est logique de le dessiner, comme vous l'avez fait, mais avec une résolution de niveau unitaire.
Votre mise à jour 1 et 2 Mettez-moi toujours de penser qu'il y a une unité de Vos unités utilisent (directement IME, l'ensemble minimum de packages à inclure est
Je dis que je comprends que c'est la signification littérale de ce message d'erreur, cependant, que dans ce cas, toutes ces unités sont dûment incluses (explicitement) dans chaque paquet, et qu'il n'y a pas d'unités implicites ou manquantes.
Mais tous les paquets sont-ils référencés qui doivent être référencés? Sinon, une unité peut être liée directement.
Je le crois, mais il est très très difficile de vérifier cela. En plus des suspects de VCL habituels que vous avez énumérés, il existe plus de 100 autres packages dans cet "écosystème de code" qui pourrait être logement une unité qui crée ainsi une dépendance manquée. Étant donné que les unités en question ont été soigneusement vérifiées, il semble que les dépendances manquées autres que celles des messages d'erreur indiquent un bogue de compilateur d'une sorte.
Je crois à peine dans un bogue de compilateur, dans ce cas. Si je vois quelque chose comme ça se produisant, IME c'est un bug dans ma configuration.
Les deux sont possibles à la fois. Le bogue de ma configuration est presque indécouvable en raison d'un manque de messages d'erreur compilateur corrects. Les avertissements normaux «Importation implicite» ne se produisent pas, et quelque chose d'autre se passe mal en même temps, et le mauvais message d'erreur sort. Aucune quantité de fidélisation avec d'autres options ne peut coaxer un message d'emballage correct de la configuration.
@Warren: hmmm ... ne peut pas dire ce qui se passe là-bas, désolé. L'avertissement «implicite» devrait au moins se produire une fois.
J'ai eu un paquet de 10 unités qui ne nécessitent que vclsmp.dcp
Dans le projet qui donne l'erreur doit être ajouté au besoin. erreur DCP.
Dans votre cas:
[Erreur fatale DCC] MyUnit3.Pas (244): E2411 Unité dans l'emballage B_DSGN XBAT fait référence à l'unité Qbee qui n'est trouvée dans aucun package. Doit faire référence aux unités emballées uniquement aux unités emballées
Dans l'emballage où il it MyUnit.PAS Drive, Ajouter in requis: QBee
au moins j'ai réussi à le faire.
Vous utilisez l'unité 1- Vous n'avez pas ajouté la liste 2- Si qbee est déjà contenté dans un autre paquet, appelez-le original_package alors vous devez ajouter le package à la liste requiert fort> b_dsgn et ne contient pas l'unité.
3- Le original_package a
Dans son fichier DPK est donc d'abord ce que vous avez à faire est de tourner 4-vous n'avez probablement pas xbat dans b_dsgn mais vous l'avez dans un autre paquet moyen, appelez-le bonne chance {$ implicitbuild sur}
implicitbuild éteint et de construire original_package après que vous puissiez construire votre
implicitbuild off.
Si je vous comprends correctement, lorsque "Reconstruire au besoin" est vérifié, le bâtiment C déclenche une reconstruction de B, qui déclenche ensuite une reconstruction de B_DSGN (qui échoue) - Êtes-vous sûr de ne pas avoir introduit une sorte de dépendance circulaire de C / C_DSGN à B / B_DSGN?
Utilisez-vous Emballage faible ?
Bonne question.Tomornor au travail, je rechercherai des références à des emballages faibles.
@Tondrej: Je ne vois pas à quel point la pacabise a rien à voir avec ça. Cela ne change pas quelle unité est dans laquelle le paquet contient et quelles unités sont référencées. Cela ne change que la manière dont les unités sont liées (toujours, dans le cadre de la BPL ou uniquement en cas de besoin, copiées du fichier .DCP et liés directement).
FWIW, dans lequel le paquet est Qbee et dans quel paquet est xbat?
J'ai trouvé beaucoup de références à faimpackagelink et à les supprimer expérimentalement. Cette erreur s'en va, et l'ensemble de l'IDE se bloque, chaque fois que je construis.
Imo, c'est un bug de compilateur DELPHI.
Je vois que vous utilisez xe. Mais j'ai le même problème ici avec XE7. Bon sang, quand un bogue est introduit à Delphi, il colle pour au moins 7 versions !!! Mise à jour: Plus de 7 versions depuis que Cochran le confirme sur Delphi 2009.