Scolring - Forum

ORNis

Member

Registered: 27-Mar-2013

Posts: 1

Portage Linux / Package Debian

Bonjour à tous,

je suis actuellement "Packageur"/mainteneur pour une petite distribution linux axée sur les besoins des archéologues (ArcheOS: https://github.com/archeos, distribution fondée sur Debian). Un certain nombre de mes collègues ont évalué openspace3D sous windows et lui ont trouvé un très fort potentiel pour la valorisation des modèles 3D. J'ai alors opéré un petit sondage il y'a quelques temps dans le dépôt svn de scol et ce forum afin d'évaluer la faisabilité d'un package pour la distribution. Peut-être que je me trompe mais il en ressort que:
- Potentiellement c'est faisable, de part le choix des bibliothèque tierces (Ogre, aruco...) qui sont 100% compatibles linux et parfois déjà empaquetés pour Debian.
- En détail, utilisation d'un certain nombre d'API spécifiques à Windows (inclusion de window.h dans scol par exemple...) nécessitent la réalisation d'un "portage" spécifique avant tout tentative de packaging.

Donc j'aurai quelques questions à vous poser à ce sujet:
- Travaillez vous sur activement sur un port "natif" Linux et auriez vous besoin (et accepteriez vous) les collaborations sur ce projet ?
- La base de code dans le dépôt est particulièrement énorme (scol, plugins, voyager, openspace3D, bibliothèques tierces). Pourriez-vous m'indiquer quelles sont les dépendances *minimales* nécessaires afin de faire fonctionner openspace3D ?
- Parmi ces dépendances (plugins...) quelles sont celles qui poseraient le plus de problème à porter sur linux ?

Merci d'avance pour vos précieuses réponses,
A très bientôt,
Romain

iri

Admin. / Scol language & Scol apps developer

From: France

Registered: 22-Feb-2009

Posts: 2,024

Website

Re: Portage Linux / Package Debian

Bonjour,

Nous y travaillons ... lorsque le temps nous le permet.

1er point : Certaines bibliothèques sont déjà prévues, quelques unes devraient même être déjà native sur ce plan. Ce n'est malheureusement pas les plus fondamentales.

2nd point : Scol a eu une version stable Linux. Elle est cependant totalement obsolète aujourd'hui.

3e point : le noyau (kernel) a commencé à être nettoyé, pas mal de travail a été fait, notamment sur ce point. Les headers spécifiques à Windows sont progressivement éliminés lorsque la compilation n'est pas sous .. Windows.
Un « SDK » a été fait, supportant entre autres choses, la différentiation native Windows / Linux.

4e point : toute la partie 2D est à revoir : elle s'appuie sur GTK 1.2 qui n'est plus supportée par les distributions modernes. Un support GTK 3.0 est en cours (mais à l'arrêt ces derniers mois, faute de temps).

5e point : passage à une arborescence propre, et non plus dans le HOME de l'utilisateur (-> /usr/bin, /usr/lib notamment).

6e point : Le noyau évidemment, les bibliothèques lib2dOS, SO3Engine, Security. Ensuite, les bibliothèques dépendant de certains plugITs utilisés dans Openspace3d.
Il me semble néanmoins que le noyau est prioritaire (remise à niveau, nettoyage du vieux code restant) suivi de près par la 2d (soit porter de GTK 1.2 -> 3.0 soit poursuivre le dev d'une nouvelle lib GTK 3.0 native et passerelle avec les APIs 2d existantes). Ce sont les deux gros morceaux. Y a du boulot mais pas insurmontable.

7e point : Openspace3d en lui-même ne demande aucun portage, Scol fonctionnant sur le principe des machines virtuelles, le code source est le même quelque soit la plate forme. C'est donc bien Scol qu'il convient de porter.

8e point : Scol est actif sous Windows, les demandes étant là. Sous Linux, malheureusement, c'est suivant les disponibilités. Nous acceptons bien évidemment tous les contributeurs ou même tous les développeurs qui souhaiteraient travailler en profondeur.

9e point : n'hésite donc pas à poser toutes les questions ! À cet effet, bascule dans la rubrique Scol du forum (puisque l'éventuel portage porte sur Scol et non Openspace3d).

Enfin, merci pour ce retour et l'intérêt marqué.

Nodrev

Scol Language & OS3D developer

From: Nantes, France

Registered: 29-Dec-2009

Posts: 197

Re: Portage Linux / Package Debian

Salut,

Juste pour compléter la réponse de Iri, le noyau scol compile déjà en natif sous linux, même si j'ai du pour cela désactiver un paquet de fonctionnalités importantes (genre le réseau). Donc ça m'étonnerais que ça fonctionne.
La première étape serait de réécrire l’exécutable qui charge la dll du noyau (scol.exe, projet usmwin) en multiplateforme (au lieu de reprendre l'ancien exe linux qui de mon point de vue est pourri), en plus ça permettrait de n'avoir qu'une seule base de code pour le lanceur, donc moins dur à maintenir. J'avais commencé à en écrire un, mais suis incapable de me rappeler ce que j'en ai fait . Par contre, j'avais rajouté tout ce qu'il fallait dans le kernel pour permettre de charger la dll du noyau (genre des defines pour les appels natifs des fonctions de chargement dll sous win/linux/?mac?).
Ensuite, le gros gros point qui demande beaucoup de refacto est la gestion des messages windows. En effet, et je ne comprend d'ailleur pas pourquoi ça a été fait ainsi, la vm utilise des messages windows en interne pour s'envoyer du travail (voir le code relatif à l'appel des 'fonctions reflexives' (des callback scol en fait), dans myLoop.cpp).
Enfin, la troisième étape est comme l'a indiqué Iri de finir la version de la lib2d GTK.
Ensuite, ce sera "peace of cake" comme le disais mon oncle Duke.

<edit>J'ai oublié de dire que l'on a convertit presque tout les projets en cmake il n'y a pas longtemps, donc on peut générer les makefile avec. Le SDK linux dont parle Iri devrait être ammené à disparaitre, il faut mieux utiliser des includes vers les fichiers du kernel comme on a fait dans les projets convertis en cmake).</edit>
<edit2>D'ailleurs Iri, il faudrait que l'on voit pour les plugins dont tu t'occupes si on peut les passer en cmake un de ces quatre</edit2>

Last edited by Nodrev (27-Mar-2013 16:55:24)

iri

Admin. / Scol language & Scol apps developer

From: France

Registered: 22-Feb-2009

Posts: 2,024

Website

Re: Portage Linux / Package Debian

La première étape serait de réécrire l’exécutable qui charge la dll du noyau (scol.exe, projet usmwin) en multiplateforme (au lieu de reprendre l'ancien exe linux qui de mon point de vue est pourri).

Oui, j'avais testé avec les fonctions standards dlopen / dlsym, ... ce qui fonctionnait très bien. L'ancien noyau est à proscrire en effet et, comme je disais, totalement obsolète de toutes façons.

Ensuite, le gros gros point qui demande beaucoup de refacto est la gestion des messages windows. En effet, et je ne comprend d'ailleur pas pourquoi ça a été fait ainsi, la vm utilise des messages windows en interne pour s'envoyer du travail (voir le code relatif à l'appel des 'fonctions reflexives' (des callback scol en fait), dans myLoop.cpp).

C'est un héritage des tout débuts, un choix effectué dans les années 96 / 98, pour s'appuyer un max sur l'OS et alléger la VM (cf contraintes de l'époque). La méthode a perduré ensuite.
Tout comme le nettoyage que j'évoquais des bouts de code répétitifs, inutiles, gourmands, inmaintenable. Tu fais bien de le rappeler :)

Enfin, la troisième étape est comme l'a indiqué Iri de finir la version de la lib2d GTK.

Je vais m'y remettre, puisque la demande semble venir !

J'ai oublié de dire que l'on a convertit presque tout les projets en cmake il n'y a pas longtemps, donc on peut générer les makefile avec. Le SDK linux dont parle Iri devrait être ammené à disparaitre, il faut mieux utiliser des includes vers les fichiers du kernel comme on a fait dans les projets convertis en cmake).

Très bon travail que tu as fais d'ailleurs :)

D'ailleurs Iri, il faudrait que l'on voit pour les plugins dont tu t'occupes si on peut les passer en cmake un de ces quatre

Fait en partie.