2009-09-15 6 views
1

J'essaie de configurer une version automatisée de mon application Windows CE. Cependant, nous évoluons notre plate-forme en même temps que notre application (en ajoutant cartes d'extension, de nouveaux services, etc.). Je veux être en mesure d'associer ma version d'application à une version du SDK et d'avoir plusieurs versions de installé sur le SDK (option moins recommandée) ou d'avoir le SDK versionné avec mon application (option la plus préférable). Je veux être en mesure d'exécuter des versions parallèles afin que le SDK soit local pour mon projet et non partagé entre les projets.Générations automatisées d'applications Windows CE

Actuellement ce que je suis en mesure de le faire est d'installer le SDK et déplacer les en-têtes et les bibliothèques à mon projet, puis ajouter le chemin par rapport à mon projet comprend et libs. Ma question est: il y a plus de choses que les en-têtes et bibliothèques qui sont installés avec le SDK donc je pourrais avoir des problèmes si je construis une application avec des en-têtes et des libs plus anciens et un nouveau SDK installé (ou plus récent header et libs que le SDK installé)? Une autre façon serait de rediriger Visual Studio/les outils de ligne de commande vers mon propre header/libs et Properties.xml (mais je n'ai pas compris comment faire cela).

Est-ce que quelqu'un a déjà fait ça?

Merci,

Alexis

+0

S'il ne s'agit pas d'une question Platfom-Builder, supprimez l'étiquette. Veuillez clarifier les points suivants: Vous souhaitez utiliser des en-têtes et des bibliothèques à partir d'un SDK spécifique, puis rendre toutes les générations futures non dépendantes de ce SDK? – Shaihi

+0

Désolé, la balise Platfom-Builder a été supprimée. Je veux que ma construction soit complètement indépendante du programme d'installation du SDK. Je souhaite que toutes les informations sur l'installateur SDK soient contenues dans mon projet. Donc, quoi que fasse le SDK (installer les en-têtes et les libs, et toutes les autres actions), je veux qu'il soit contenu dans mon projet afin que mes constructions automatisées ne dépendent pas d'un installateur. Cependant, je ne suis pas sûr que tout ce que fait le SDK et je veux m'assurer que l'inclusion de nouveaux en-têtes et bibliothèques de SDK est suffisante pour rendre mon projet indépendant du programme d'installation du SDK. – Alexis

Répondre

1

Il s'agit en fait d'une question assez vaste couvrant quelques domaines. Regardons d'abord ce qu'est réellement un SDK et ce qu'il contient. Lorsque vous créez une plate-forme, vous incluez les éléments du catalogue. Chacun de ces éléments possède un ensemble de fichiers en-tête et lib associés. Lorsque vous développez un SDK, le rouleau fusionne tous ces en-têtes et bibliothèques pour chaque composant de catalogue, par processeur (car un SDK peut prendre en charge plusieurs processeurs). Il ajoute également dans tous les fichiers «supplémentaires» que vous définissez dans votre plate-forme BSP (comme l'émulateur BSP inclura l'image de l'émulateur) et il inclut également tous les fichiers supplémentaires spécifiquement définis dans la définition du SDK.

Quand le contenu d'un SDK change-t-il? Eh bien, chaque fois que vous apportez une modification aux éléments de catalogue inclus dans votre plate-forme, ou lorsque vous choisissez explicitement d'ajouter ou de supprimer les fichiers supplémentaires définis dans le rouleau SDK.

Pour l'automatisation, c'est assez simple. Ce que nous avons tendance à faire (et cela a fonctionné pendant des années avec de nombreuses entreprises) est de définir un très, très large ensemble de composants catlaog. Fondamentalement jeter dans l'évier de la cuisine du catalogue.

Ne pas ajouter des fichiers personnalisés (donc si vous avez des en-têtes personnalisés pour un pilote ou autre, ne les incluez pas dans le SDK). Au lieu de cela, publiez ces fichiers manuellement dans un dossier commun. Ajoutez ce dossier commun aux applications "Chemin d'inclusion des fichiers supplémentaires".

Maintenant, vous pouvez modifier la plate-forme à volonté sans affecter l'application. Le seul problème potentiel est que vous pouvez utiliser un en-tête ou une bibliothèque que vous finissez par couper à partir de la plate-forme en raison de restrictions de licence ou de taille.

L'automatisation de tout cela est vraiment une question complètement distincte, et il ne semble pas que vous demandiez réellement comment faire l'automatisation de la construction elle-même.

+0

Merci pour la réponse. Cela ressemble vraiment à une solution potentielle. En général, j'essayais d'éviter d'avoir à installer n'importe quel SDK sur le serveur de build (ne pas installer Visual Studio et Platform Builder serait le meilleur et avoir aussi le contrôle de configuration) mais il semble que le SDK définisse des clés t Trace pour satisfaire l'environnement de construction que je construis avec ce SDK spécifique sans installer le SDK. Mais votre solution est générique et fonctionnerait sur plusieurs projets. – Alexis

+0

Oui, nous n'avons jamais été en mesure de devoir installer Studio et le SDK "général" sur le serveur de construction, bien que nous ayons un SDK, c'était une chose unique, donc la maintenance est faible. – ctacke

0

On dirait que vous voulez jouer avec l'environnement PATH que PB suce ses informations. Je veux dire (d'après ce que je comprends), vous voulez que 2 builds prennent des fichiers de 2 endroits différents, non? Dans ce cas, vous pouvez exécuter différents fichiers de traitement par lots pour configurer les paramètres d'environnement appropriés, puis la construction sera différente pour chaque fichier de traitement par lots. Le blog suivant présente un excellent aperçu des outils de génération de Platform Builder (link).
Vous voulez jouer avec la macro INCLUDES pour contrôler où PB prend les fichiers d'en-têtes et pour les lier à différentes bibliothèques chaque fois que vous devrez faire en sorte que les chemins des bibliothèques soient composés d'une macro que vous définirez dans fichier batch, par exemple:
SOURCELIBS = \
$ (_ MY_PREDEFINED_PATH_TO_THE_LIBS) \ lib \ libName.lib

Puis dans le fichier batch que vous mettrez un autre

_MY_PREDEFINED_PATH_TO_THE_LIBS
+0

Merci pour la réponse. Il ne s'agit pas d'une question liée à Platform Builder. J'utilise le Visual Studio 2005 standard avec un SDK généré à partir de Paltform Builder. Ma question concerne le SDK: qu'est-ce qu'il installe et est-il sûr de ne stocker/forcer les en-têtes et libs localement dans mon projet que pour rendre la version SDK indépendante. – Alexis

0

Je vous suggère de faire face en utilisant une stratégie de gestion de la configuration throrough (version): écartez la possibilité de mélanger des versions de fichiers d'en-tête et de librar sies Même si cela fonctionne, c'est certainement une configuration non prise en charge, qui peut vous donner des bizarreries étranges. Mais si vous pouvez garantir que tous les outils sont sous contrôle de version, vous pouvez toujours restaurer une version des outils. . Méfiez-vous des associations de registre. Si vous pouvez créer des versions binaires identiques (c'est-à-dire sans dates/numéros de build incorporés!), Vous pouvez vérifier que vous pouvez reconstruire le même binaire sur deux machines différentes lorsque vous passez à une certaine version dans la gestion de configuration. Cela va coûter beaucoup de temps, mais pas autant de temps qu'il en coûtera quand vous serez dans un environnement incontrôlé avec des conflits de version SDK!

+0

Merci Aadrian.Nous n'avons pas encore les outils sous la gestion des sources. Je cherchais de l'aide concernant les paramètres spécialisés et cachés dans les outils Microsoft, mais je pense que pour l'instant je continuerai à gérer les en-têtes et les bibliothèques du SDK. Toutes les bonnes et utiles suggestions cependant. – Alexis

0

Nous générons le SDK, mais copions ensuite les bibliothèques/en-têtes dans un dossier svn partagé. Ce dossier est mis à jour chaque fois que nous créons un nouveau SDK. La seule chose dont nous avons besoin pour le SDK est d'installer les plates-formes de processeur dans Visual Studio. Une fois cela fait, notre application tire dans les en-têtes/libs en utilisant svn: externals. De cette façon, les anciennes versions de notre application peuvent encore être éditées et compilées avec leur SDK d'origine. Sinon, nous devrons désinstaller/réinstaller manuellement le SDK chaque fois que nous souhaitons travailler avec une branche différente.

Une fois j'ai regardé dans l'extraction de tous les fichiers du SDK, de sorte qu'il installe seulement les entrées de registre VS nécessaires pour la plate-forme, mais je suis devenu fainéant et ai abandonné.

Questions connexes