Paquet NuGet

[ctxnop]

Après m'être renseigné un peu plus, l'extension NuGet n'est disponible que pour Visual Studio 2010 et supérieur (dont la preview de 2013).
Donc pour 2008 ça tombe un peu à l'eau.
Cependant il semblerait qu'on puisse bidouiller pour faire passer NuGet tout de même. De plus il peut s'utiliser en dehors de Visual Studio, en stand alone ou via un autre outil qui le supporte (genre WebMatrix). Donc on peut potentiellement l'utiliser quand même.

Par contre je doute que dans ces cas on profite de la configuration automatique du projet. Ça se transformera sans doute en simple downloader.

Du coup je pense que dans les prochaines versions, si tu es d'accord, je n'inclurai pas les binaires pour Visual Studio antérieurs a 2010. Ça allègera le poids du paquet.

[Laurent]

No problem.

[ctxnop]

Bonjour,
Un an jour pour jour, jolie coïncidence...
Je te contacte car j'ai reçu une demande vis à vis du package nuget : le support de Visual Studio 2013.
Cette version n'étant pas disponible sur le site j'ai quelques des questions :

• Est-ce que tu comptes mettre à dispo une version pour VS2013 ?
• Si non, je peux compiler les sources, mais est-ce que tu compiles avec des options particulières pour les versions que tu proposes ? (histoire que je mette les mêmes)
• Si je compile, est-ce que tu voudra un zip pour mettre cette version dispo sur ton site ?
• Pour le paquet nuget j'envisage un découpage en plein de sous-paquets (un pour sfml-graphics, un autre pour sfml-audio, etc...) est-ce que tu vois quelque chose qui pourrait s'opposer à ce découpage ?
• Pour gérer le SFML_STATIC je ne vois pas d'autre solution qu'un découpage avec un paquet static et un dynamique, ca te dérange ?
• Si tu es ok pour le découpage, j'aurais besoin d'avoir plus d'info sur les dépendances entre les modules

Je sais qu'en découpant le paquet en plusieurs on se retrouve avec une distribution différente de celle du site, cependant nuget est un système de résolution de dépendance, pas vraiment un système de téléchargement. Les gens s'attendent souvent à avoir un paquet par DLL/Assembly car on ajoute aux projet une "référence nuget" au même titre qu'on ajoute une référence à une assembly locale.
De plus, contrairement au site, nuget ne permet pas de télécharger que la bonne version de Visual Studio, il télécharge tout et configure pour utiliser la version correspondante au Visual Studio, ce qui donne des paquets très lourds à télécharger.

[Laurent]

Est-ce que tu comptes mettre à dispo une version pour VS2013 ?

Non. Uniquement pour la prochaine release (SFML 2.2).

Si non, je peux compiler les sources, mais est-ce que tu compiles avec des options particulières pour les versions que tu proposes ? (histoire que je mette les mêmes)

Non. CMake avec les options par défaut te génère une release "officielle".

Si je compile, est-ce que tu voudra un zip pour mettre cette version dispo sur ton site ?

Non

Note qu'on a déjà des nightly builds pour Visual Studio 2013, par contre je ne sais pas si on a SFML 2.1.

Pour le paquet nuget j'envisage un découpage en plein de sous-paquets (un pour sfml-graphics, un autre pour sfml-audio, etc...) est-ce que tu vois quelque chose qui pourrait s'opposer à ce découpage ?

Pas de souci, mais comment vas-tu gérer les dépendances entre modules ? Par exemple, si je prends le paquet sfml-audio et le paquet sfml-graphics, je n'aurais bien qu'une seule version de sfml-system ?

Pour gérer le SFML_STATIC je ne vois pas d'autre solution qu'un découpage avec un paquet static et un dynamique, ca te dérange ?

Non ça ne me dérange pas. Mais pourquoi ne pas mettre les deux dans un même paquet ?

Si tu es ok pour le découpage, j'aurais besoin d'avoir plus d'info sur les dépendances entre les modules

Tout dépend de sfml-system, et sfml-graphics dépend aussi de sfml-window.

[ctxnop]

Pour les dépendances normalement nuget se débrouille pas trop mal et donc oui, il y aura bien qu'un seul sfml-system si tu prend sfml-audio+sfml-graphics.
Évidemment je testerai que ça se comporte bien comme ça avant d'upload.

Pour la question de séparer les statiques des dynamiques c'est parce que nuget configure le projet (c'est tout son intérêt d'ailleurs).
Pour le moment il configure pour utiliser les dynamiques, c'est à dire qu'il n'ajoute pas SFML_STATIC au preprocesseur et fait un link vers les .lib "normaux".
La configuration est "injectée" dans le projet et n'est pas facile d'accès pour modifier si elle ne convient pas.
Du coup si on veut passer en static il faut beaucoup bidouiller, donc je pense que personne ne changera la config par défaut, celui qui veut utiliser les statiques aura plus simple de passer par le site.
De plus, dans la mesure où on est sensé faire soit du static soit du dynamique, mais pas les deux, c'est un peu dommage de télécharger les libs dynamique si on va faire du static, et vice versa.

Je n'ai pas encore fait d'essai sur la séparation statique/dynamique, donc pour le moment je n'en sais pas beaucoup plus.
J'aimerai bien un système qui permette de sélectionner correctement les .lib selon que SFML_STATIC est définit ou non, mais à priori nuget en est dépourvu

[ctxnop]

Salut !
Je n'ai pas du tout eu le temps de m'occuper des paquets nugets hier, désolé.
J'ai donc tout fais ce soir.

On a maintenant un paquet par module et on est donc capable de ne prendre que le module audio par exemple. Les dépendances sont gérées correctement.
Pour essai j'ai fais un projet dans lequel j'ai installé uniquement "sfml-graphics", nuget à automatiquement ajouté system et window. Par la suite j'ai ajouté "audio", et nuget n'a pas dupliqué system. Donc ça à l'air de tourner plutôt pas mal.

Je n'ai pas fais la séparation en static/dynamique finalement car en me baladant dans la doc de CoApp je suis tombé sur comment gérer les deux dans le même paquet. Le seul truc que j'ignore pour le moment c'est comment l'utilisateur final peut choisir. Par défaut c'est dynamic.

J'ai upload les paquets, c'est donc prêt à utilisation.
Pour info, on dénombre pas loin de 700 downloads sur les anciens paquets.

[Laurent]

Fantastique, merci

[ctxnop]

J'ai trouvé comment l'utilisateur peut choisir entre static et dynamic, il y a un noeud de configuration qui est apparut dans les propriétés du projet, cf la capture.

La bonne nouvelle est que SFML_STATIC est automatiquement définit quand on choisit l'option dans cette fenêtre.

Les mauvaises nouvelles c'est que, d'une part, l'utilisateur peut choisir du static pour sfml-graphics et du dynamique pour sfml-window, ce qui ne donnera pas un bon résultat.
D'autre part, mon essai ne compile pas...
Je n'ai pas le temps la de suite d'investiguer plus que ça. Peut être que ça vient de ma compilation de VS2013, peut être que ça viens de mauvaises options, peut être qu'il s'agit d'un foirage dans la construction du paquet... J'essaierai de voir ça rapidement.

Par contre, l'utilisation de la sfml dans sa forme DLL, ce qui est le cas par défaut, fonctionne bien (j'ai déjà eu des retours de deux personnes pour me dire que ça roule).

[ctxnop]

Bon voilà, j'ai enfin eu le temps d'investiguer.
Bonne nouvelle : les paquets fonctionnent bien, il s'agit bien d'une configuration de Visual Studio.
En fait c'est l'histoire du /MT(d) vs /MD(d) comme quasiment toujours, sauf qu'il y a une fourberie supplémentaire...
En fait définir à /MT(d) dans la page d'option habituelle n'a aucun effet... Il faut définir cette option dans le noeud "Project Master Settings", visible dans ma capture, juste au dessus du noeud "Référenced Packages".
Je ne sais pas pourquoi ils ont fait ça comme ça plutôt que d'utiliser l'option normale...

Autre détail, les DLLs sont copiées dans le répertoire de sortie même si on à choisi le mode static. Ce qui est utile pour les dépendances qui restent des DLLs (genre libsndfile-1.dll), mais les DLLs de la sfml sont également copiées alors que ce n'est pas utile.
J'ai vérifié, c'est bien le static qui est utilisé, si on supprime les DLLs l'exe fonctionne toujours.
Par contre, je ne pense pas pouvoir changer le fait que nuget copie ces DLLs inutilement.

Et sinon, les paquets sont online depuis 1 semaine et on compte déjà une vingtaine d'utilisation

[ctxnop]

Bonjour,

J'ai mis à jour les paquets nuget pour la version 2.2.

Cependant je me suis un peu foiré, j'ai utilisé un ancien script moisi et n'ai vu l'erreur qu'après upload...
J'ai aussitôt désactivé les paquets mais je ne peux les supprimer ni les remplacer (limitations du site).
Du coup j'ai généré de nouveau paquets mais avec la version 2.2.0.1.
Je pense que ça ne posera pas de problèmes étant donné que tu n'utilises que 2 nombres pour les releases a priori.

J'en ai également profité pour mettre en ligne les scripts de création de paquets afin que d'autres puissent créer des paquets personnalisés ou autre : https://github.com/ctxnop/sfml-nuget.

Ne pas hésiter à me dire s'il y a des problèmes.

Et bonne année bien sur !