Je suis Développeur de jeu indie Travailler sur la plate-forme Windows, mais je n'ai vraiment que peu d'expérience avec Linux et de déployer des applications pour cela. Je polissais mon jeu écrit en C ++ 11 basé sur SDL 2.0 avec plusieurs autres dépendances multi-plateforme (comme AngelScript ou PugiXML) sur Windows et je veux distribuer sur Linux et aussi avoir quelques questions à ce sujet. Le jeu est commercial, source fermée qui est actuellement sur la greenlite de Steam's, mais je souhaite distribuer une version alpha gratuite téléchargeable à partir de ma site Web, quel que soit le statut de Greenlite.
1.) Les principales distributions Linux sont-elles compatibles avec compatibilité? Ou dois-je compiler mon jeu sur chaque distribution / plate-forme prise en charge?
2.) Si tel est le cas, quelles distributions / plates-formes sont des choix raisonnables pour soutenir?
3.) Quel est le meilleur moyen d'installer une application et ses dépendances sur Linux? J'ai lu sur les systèmes Deb et RPM, mais il est toujours confus - y a-t-il un moyen de générer automatiquement des packages de configuration pour diverses distributions?
4.) Comment fonctionne la vapeur avec Linux? Comment devrais-je préparer mon application pour la distribution via elle?
Excusez-moi si je pose des questions erronées, tout le monde de Linux est joli nouveau pour moi et j'ai perdu la lecture de divers articles et pages manuelles ...
3 Réponses :
Je ne suis pas un développeur de jeu et je viens de la communauté open source, vous ne pouvez donc pas vraiment vous conseiller sur la livraison des fichiers binaires. Je vais essayer de répondre à certaines de vos questions cependant:
Valve a un runtime de vapeur Vous pouvez cibler sur Linux ( https://github.com/valvesoftware/steam -Runtime ) - Ce serait la meilleure façon de porter votre jeu. Je l'ai vu mentionné dans l'une de leurs vidéos de développement Linux sur YouTube, ma compréhension est-elle en train de faire un tas de bibliothèques inclusivement SDL et il est configuré pour émuler une version spécifique de Ubuntu. Donc, si vous écrivez votre jeu contre le runtime Steam, il fonctionnera dans n'importe quelle distribution de Linux que Steam a été porté aussi.
Quant à l'emballage de façon native Votre jeu Une chose à considérer est si vous l'emballez comme un deb ou un régime et demandez-lui de dépendre de la distribution fournie par les liberies que votre application peut casser lorsque les bibliothèques sont mises à jour (certaines distributions mettent à jour les libs - d'autres sont plus stables). La liaison dynamique contre les bibliothèques système fonctionne bien pour une source ouverte puisque les gens peuvent corriger le code lorsque les liberies ne changent pas idéales pour des trucs proches.
Vous pouvez lier de manière statique à votre binaire au moment de la construction, ce qui signifie que vous avez un binaire de taille plus grand. Mais que vous n'avez pas à vous soucier de l'application rompre lorsque des libs sont mis à jour.
Certains programmes tels que Chrome Bundle leurs propres libs (qui sont essentiellement des fourchettes du système Libs) à nouveau, cela rend la taille de téléchargement beaucoup plus grande, mais aussi de causer des problèmes de sécurité, les gens ont tendance à les froncer les sourcils. (Voir: http://lwn.net/articles/378865/ )
Je ne peux tout simplement pas lier statiquement tout, car certaines de mes dépendances sont sous gpl
Vous pouvez probablement regrouper les Libs (mais vous auriez besoin de fournir un code source pour les libs GPLL'D que vous avez enfui - ou au moins un lien vers la source). Ou vous pouvez créer de manière dynamique sur les Libs système et accepter la rupture peut se produire à un moment donné à l'avenir. Le cynique en moi soupçonne qu'il serait beaucoup plus facile si vous pouviez ouvrir la source de votre jeu - vous utilisez déjà des bibliothèques open source après tout.
@PIuTrk Si vos libs sont GPL, votre code est maintenant aussi; Vous pouvez créer un lien vers le code LGPL sans rendre votre code ouvert mais le code GPL nécessite votre code est également gpl (ou vous atteignez un autre arrangement de licences avec les auteurs des Libs).
@Elliottfrisch Ce n'est pas vrai, tant que le code GPL est lié à un objet partagé (ou de la DLL dans Windows), pas dans l'exécutable principal lui-même.
@PIOTRK Demandez à votre avocat. Wikipedia dit Ce différend clé est de savoir si un logiciel non-GPL peut légalement lier de manière statique ou lier dynamiquement vers des bibliothèques GPL. Différentes opinions existent sur cette question. Le GPL est clair pour que toutes les œuvres de code dérivées sous la GPL doivent elles-mêmes être sous la GPL .
@Elliottfrisch Oh, je vois, je pensais que la matière était réglée (au moins dans mon pays qui est la Pologne) - mais j'ai découvert que ce n'est pas le cas. Heureusement, ma seule dépendance de la GPL n'est pas un disjoncteur de l'affaire, je peux vivre sans elle.
@Piotrk Il y a probablement une version BSD autour, mais oui, il y a une raison pour laquelle les gars BSD font des choses comme libedit au lieu de en utilisant readline.
@Elliottfrisch Yeah, et toujours quelqu'un ose appeler gpl "gratuit comme dans la liberté d'expression" ... Les licences de type virus sont douloureuses dans le cou, elles n'impliquent certainement pas la liberté. J'ai soutenu et apporté quelques projets open source dans le passé, libérant mon code sur des licences de type X11 / BSD. Je ne reçois tout simplement pas la "liberté" derrière gpl. Ce n'est pas conçu comme allumeur de guerre de flamme, merci d'avance ...
@Piotrk sera juste, personne ne vous fait boire de la bière GPL. Ils exigent juste que si vous incluez quelque chose d'une bière GPL dans votre bière, il s'agit également de GPL. La bière gratuite est la meilleure bière.
Je suis tout à fait en désaccord avec votre attitude à propos de la GPL, il est "gratuit comme dans la parole" et tout comme comment dans certains pays, ils ont une constitut pour protéger la liberté d'expression, GPL a une licence pour protéger la liberté du logiciel. Si j'écris une bibliothèque (ou un autre code) et publiez-la sous la GPL et que vous le trouvez suffisamment utile pour utiliser mon code, son seul salon est capable de prendre votre code modifié moi-même. Alors peut-être pour vous, c'est un virus pour moi une caractéristique.
1.) Non, abis des distributions principales Linux ne sont pas entièrement compatibles. Dans un sens étroit, ils sont la plupart du temps compatibles. Mais dans un sens plus large, de nombreuses différences dans lesquelles certains éléments du système fonctionnent sont configurés, etc., OTOH, la fabrication de "packages" n'est pas un gros problème par SE < / em>, juste du travail. En outre, ce qui fonctionne pour une "grande" distribution (comme Debian) fonctionne (à peu près toujours) sur tous les dérivés (comme Ubuntu, Mint ...).
2.) Une bonne liste de démarrage à l'appui est la suivante: Debian (.deb), Redhat et Fedora (.rpm à la fois). Leurs formats et outils de colis sont matures et bien connus. Cela "couvrir" beaucoup de dérivés.
3.) Il existe des constructeurs de paquets "transversaux", mais ne sont principalement pas à la hauteur de la tâche. Écrire un script de définition pour la plupart des formats d'emballage n'est pas difficile, une fois que vous en avez une suspension. En outre, certains outils commerciaux ont des "générateurs de script d'installation" pour Linux qui s'occupent de choses pour vous (elles ne génèrent pas .deb ou .RPM, plutôt un script de shell complexe, similaire à un programme d'installation de Windows EXE)
4.) Désolé, je ne sais pas grand chose de vapeur. O :)
Donc, de mon expérience, la meilleure façon de le faire est d'accepter la vérité laide que vous devez sélectionner quelques distributions principales et leurs versions («car les choses peuvent changer beaucoup entre les versions ) et faites des colis pour eux et testez-les souvent sur tous. Et soyez heureux que vous ne développiez pas un module / pilote de noyau à long habitude, car si vous ajoutez de suivre les changements d'API de noyau de noyau à l'image entière ... :)
Cela dépend de ce que la distribution est dérivée. Généralement, il n'est pas nécessaire de recompiler un programme sur quelque chose comme Ubuntu sous Fedora tant que le code reste inchangé. Depuis que Ubuntu et Fedora devraient utiliser les mêmes bibliothèques (bien qu'à différents endroits) et tout ce qui est lié à OpenGL serait une question de pilote; Par conséquent, il n'est guère nécessaire de recompiler votre logiciel. Je serais extrêmement surpris si vous deviez recompiler votre logiciel puisque toutes les distributions utilisent à peu près le même ensemble de bibliothèques / got Bash / utilisent le noyau Linux mais ont des gestionnaires de paquet différents. La dernière partie est l'endroit où il est complexe:
Les distributions précitées ont des gestionnaires de paquets différents qui vous oblige à reconditionner votre logiciel en conséquence. Vous pouvez libérer des fichiers binaires pré-compilés dans le cadre d'un fichier tar.gz et il suffit de disposer de configurer les responsables du logiciel pour vous; Bien que si vous souhaitez contrôler comment votre logiciel est distribué, vous devriez mieux le faire vous-même. En raison de cette question entourant les nombreux gestionnaires de forfaits, les gens ont toujours recours à la recomposition du code source via un fichier de fabrication qui peut être généré par CMAKE. Cela ne se produit que si certaines dépendances sont, pour une raison quelconque, "renommé" auquel cas en raison d'un changement de nom simple, le programme ne trouve que la dépendance. Comme il n'y a pas non plus de convention de dénomination, il rend même la vie plus difficile. La Virtue la plus importante en est la confiance et y avoir confiance en les développeurs suivant les conventions de nommage afin que tout le monde puisse faire référence au même paquet du même nom.
Les meilleures distributions à prendre en charge sont les plus populaires: Ubuntu et OpenSUSUSE seraient de grands points de départ. Linux Mint, Fedora et Red Hat et Debian utilisent des gestionnaires de paquets de l'emballage de la cimedaid.
Comme pour l'installation, vous auriez besoin d'un exécutable Bash qui déplace le contenu de votre répertoire dans les bons emplacements. En règle générale, l'application principale passe dans / usr / bin et toutes les données liées à une application vont dans le dossier à domicile. Cela dépend à nouveau de la distribution; Recherchez un répertoire .local ou vous pouvez créer un répertoire dédié à votre application cachée. Les dossiers cachés sont préfixés avec une période. Pourquoi mettre ces choses dans le dossier à domicile et quoi? Le pourquoi: parce que le dossier à domicile donne des autorisations de lecture-and-écriture à tout le monde par défaut. Le quoi: tout ce qui doit être exécuté avec l'application sans que l'utilisateur ait à l'autoriser. Les dépendances doivent ainsi être localisées dans le dossier à domicile, de préférence dans votre propre répertoire. Différentes conventions suivent; Certains peuvent être en désaccord avec moi sur celui-ci.
Vous voudrez peut-être également utiliser API de Steam qui fonctionne la plupart de ces travaux pour vous. Sous Steam, votre application peut être sous son propre répertoire et fonctionne ainsi comme une application Steam avec toutes les fonctionnalités.
http://www.steampowered.com/steamworks/
Pour en savoir plus sur la façon d'obtenir votre application sur Steam. Je dois dire que j'ai été vraiment impressionné et ils incluent même des échantillons de code. La meilleure partie est que cette API est également sur Linux. Je ne sais pas beaucoup à part de cette vapeur traiterait de l'exécution de votre application via sa propre couche. Dans lequel, il n'est pas nécessaire de distribuer de manière indépendante votre application les étapes précédentes.
Notez que vous pouvez également distribuer votre logiciel via le centre logiciel Ubuntu si vous êtes intéressé.
http://developer.ubuntu.com/apps/
Cependant, Ubuntu se concentre davantage sur l'obtention d'applications en cours d'exécution quelle que soit la plate-forme.
Sachez que Linux n'a pas de convention unique, mais sa convention est simplement dérivée du pragmatisme, pas par la théorie. À la fin de la journée, la façon dont vous voulez que votre logiciel exécuter Linux est à vous de vous.
Merci, c'est de loin la meilleure réponse ici - une question de plus: si je stocke des dépendances dans home , alors sera-t-il disponible pour tous les utilisateurs? Les actifs devraient-ils être stockés dans home aussi?
Désolé de rouvrir cela, mais avez-vous déjà été capable de faire une libération de Linux solide? J'essaie de faire la même chose et je me débats avec les différentes versions Glibc sur les différentes distributions.