Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Cross compilation Windows / Mac OSX
Bonjour à tous
j'ai vu dans un article Wiki http://fr.wikipedia.org/wiki/Lazarus que Lazarus supportait la compilation croisée entre Windows, Linux, MAC OSX et d'autres.
Arrêtez-moi si je me trompe, ça voudrait dire que avec le même code, sur un Lazarus qui tourne sur MAC OSX je peux générer directement un .EXE Windows et/ou un executable Linux (via une directive de compil ou une option de choix de plateforme) comme par exemple le permet Delphi XE2 et FMX ?
Ca paraît trop beau pour être vrai...
crossfpc permet même de le faire depuis l'IDE Delphi (sous Windows de fait)
Bonjour,Limitations propres à un SE exceptées, la réponse est ouiEnvoyé par arkhamon
Certains ont bâti un EDI de ce type à partir de FPC et Lazarus : CodeTyphon.
Voir cet article : CodeTyphon Studio 3.00
Tu peux développer ce que tu entends par "limitations du SE" ? Serait-ce du genre appel de l'API "locale" (je ne me vois effectivement pas appeler l'API windows sur MAC, ou alors les formats de fichiers (.app du MAC par exemple) ?
C'est cela mais quelquefois, ça peut être encapsulé dans une unité, donc on ne s'en rend pas compte immédiatement, même si la compilation joue en général le rôle du juge de paix...
Donc si j'ai rien raté. sur mon MAC :
- J'installe XCode dernière version
- J'installe FPC dernière version (avec éventuellement les sources)
- J'installe la dernière version de Lazarus (genre 1.0.2 ou un truc du genre)
- je code tranquillement dans Lazarus OSX en évitant soigneusement tout appel à une API "OS dépendant" (ou alors via {$IFDEF W32}
- je compile pour la plateforme que je veux : OSX ou W32 ?
- Et ca marche au final j'ai un executable natif w32 et OSX sans devori installer Lazarus sous W32 ?
Bonjour,
Non.... en tout cas, pas à mon avis. En installant Lazarus systématiquement dans les environnements de compilation, je rencontre quand même un certain nombre de problèmes... en général plutôt faciles à résoudre parce que je dispose justement de l'environnement complet de développement... Ce que ne permet pas la cross-compilation ou mal. Alors en vrac, en parcourant un peu notre forum et celui de lazarus.freepascal.org :
- Si vous utilisez les Widgets graphiques natifs de l'OS (Win ou gtk2 ou Mac) "pilotés" donc par les composants graphiques de Lazarus qui assurent l'interface, cela suppose qu'ils (les Widgets graphiques natifs de l'OS) réagissent de la même façon et disposent de méthodes équivalentes. Par exemple, le EndEllipsis n'est pas implanté dans gtk2 à ma connaissance : http://www.developpez.net/forums/d12...s-endellipsis/
- De la même façon, dans un TMemo, il est impossible de déterminer la hauteur "automatique" en gtk2 (cf http://www.lazarus.freepascal.org/index.php/topic,19413.0.html), etc, etc, etc... Peut-être pour les environnements graphiques, l'utilisation de QT rend-il la chose plus facile ?
- L'ordre des successions des évènements n'est pas nécessairement identique d'un OS à l'autre : http://www.developpez.net/forums/d12...-sous-windows/
- Même entre une compilation Win32 et Win64, on peut rencontrer des problèmes sévères... et inattendus : http://www.developpez.net/forums/d12...zeos-richmemo/ et http://www.lazarus.freepascal.org/index.php/topic,19480.0.html
Pour m'y être attelé assez longuement, je considère, jusqu'à démonstration du contraire, que la cross-compilation est une "facilité" réservée à de très simples projets ou du moins à des projets très particuliers et spécifiques. Pour le reste, la vraie facilité est d'installer Lazarus dans l'OS de compilation et d'y copier le projet : le temps "perdu" pour installer Lazarus dans chaque OS est très largement compensé par le temps gagné pour réaliser les ajustements nécessaires d'adaptation à la plateforme en question.
Cordialement. Gilles
Dernière modification par Invité ; 24/01/2013 à 18h26.
Ben voila c'est un peu mon problème : déjà je rame pour l'installer sous OSX, si je dois recommencer sous XP et maintenir une VM juste pour une compil ca m'énerve un peu...
Déjà que si je fais ce pas, je vais devoir redévelopper mon affaire (actuellment c'est sous XE2/FMX) si en plus c'est pour que ca marche pas...
Pourtant de ce que tu donnes comme exemple, une fonctionnalité qui n'existe pas dans un TMemo sous Linux n'existera pas plus si j'installe Lazarus sous Linux non ? Je comprends pas.
Bonjour,
A mon avis, il faut voir cela ainsi : Le "TMemo composant Lazarus" échange avec les composants natifs des OS (ie les Widgets). Donc dans l'exemple en question, comme il est écrit sur le forum anglophone :
Lazarus n'est qu'une interface pour piloter les objets natifs de l'OS qui n'ont rien à voir avec Lazarus. On peut tout aussi bien les piloter en C++. Mais votre conclusion est correcte : Echec et mat dans ce cas précis, comme pour le EndEllipsis. On attend gtk3, gtk4. Il y aura peut-être convergence... enfin je veux dire équivalence. Je ne suis pas du tout supporteur de la convergence. Mais au final, une fois qu'on connait la différence ou l'absence, on n'implante pas la fonction... sous Nux.The way the widgetset handles WordWrap is different under win32 and GTK2/Linux.
Under GTK2/Linux, WordWrap only has a visual effect on the memo, it does not break the lines
Under Windows the lines do break. The OS seems to handle it this way.
Il existe un projet fpGui [http://fpgui.sourceforge.net/] qui consisterait à ne pas utiliser les objets graphiques des OS. Il est commencé. Mais Lazarus est mal fonctionnel avec... je n'ai jamais réussi à compiler avec ce choix, quoi que ce soit de "suffisant". Et de plus, si je compile Lazarus avec ce "Type Composant LCL", la spécification "graphique" de Lazarus (poser des objets sur une TForm) n'est pas disponible car la TForm n'est pas un objet de fpGUI mais un objet de pilotage des Forms des OS natifs. Il faut tout faire en code ou presque. Quelle lenteur !
Reste peut-être QT que je ne connais pas. Là est peut-être une autre solution... à condition qu'elle ne soit pas un wrapper élaboré d'objets natifs d'OS.
J'ai observé également de loin vos essais avec Delphi : le forum FMX, je le consulte assez souvent. Après tests, je me suis rendu rendu compte que je n'arriverais pas à développer pour Mac OS avec cette solution. J'espère pour les efforts consentis par Embarcadero que d'autres font beaucoup mieux. Mais, je n'ai pas la patience ni la volonté de réapprendre à programmer en Pascal. Ceci dit je reste très curieux de savoir comment Embarcadero va permettre à un programmeur Pascalien de développer de manière concurrentielle une application de gestion usuelle sous Windows, cross-compilée sous Mac OS puis peut-être un jour sous Linux : [PDF, accès aux principales bases du marché dans lesquelles ne figure pas (plus) spécialement InterBase (ou FB), impression d'états conçus avec un vrai générateur, des TStringGrids un peu sophistiquées,...]. Très franchement, mais sans certitude, je me demande toujours si ce n'est pas une chimère (ie la cross-compilation pour ce type d'application). Je n'ai plus trop le temps de me poser la question ni même d'utiliser actuellement mon Lazarus dans ce type de configuration car chez nous, depuis la dernière rentrée scolaire, le "tout Windows" (y compris les serveurs) a remplacé "mon" parc hétéroclite à ma grande déception.
Il faut savoir aussi qu'il ne semble pas exister de version de Lazarus en 64 bits sous Mac OS X mais seulement une 32. Ce qui ne pose pas vraiment de problème puisque concrètement, contrairement à la situation de Linux, on se retrouve un petit peu dans celle de Windows... enfin quasiment avec les mêmes facilité et automaticité.
Donc j'en reviens toujours à cette conclusion : développer sous Win, Linux et MAC OS X est possible avec Lazarus et même TRES recommandé... à condition -justement pour gérer les différences entre les OS- d'installer Lazarus dans chacun des OS.
Ensuite vous développez, comme vous le sentez ou le prévoyez. 90%* (j'avais mis 80% au début mais c'est plus) de mes codes dans les programmes sont communs car la différenciation, je la réalise principalement dans mes composants :
J'ai développé ainsi : hormis les TForm, j'ai dérivé à partir des TCustom tous les composants graphiques que j'utilise (et d'autres d'ailleurs non graphiques). Ainsi, les TlzMemo, TlzStringGrid, TlzEdit... et ceci pour 2 raisons :
- Au début (0.9.26, 0.9.28...) pour palier les bugs des "composants originaux" quand j'en étais capable, bugs qui disparaissaient, revenaient... ou/et ajouter des méthodes. Par exemple, Enabled que j'ai remplacé par ViewOnly (couleurs de fond et de fonte à la demande en Win et Nux à la place de la fonte grise sur fond gris imposées en cas de Enabled := False),
- Corriger des insuffisances qui étaient parfois déjà des différences de comportement entre les OS. Par exemple, un problème désagréable sous Nux, en mode Enabled := False, on pouvait sélectionner quand même le contenu dans les TEdits et autres TMemos. Autre insuffisance sous tous les OS, l'absence de multiselect de lignes non contigues dans les TStringGrids, l'impossibilité de stocker dans leurs cellules autre chose que des String de type C...
Maintenant je trouve le code nettement plus stable.
Mais j'ai conservé la méthode car elle m'a permis de résoudre des problèmes d'adaptation aux différents OS... et de manière indépendante de l'avancement des projets. Le projet avance à son rythme dans un des OS. Je n'ai pas de préférence. Je développe la "couche Métier" si on peut dire même si ce terme n'est pas adapté ici. Périodiquement, je compile sur l'autre (ou les autres) OS et je teste. Là, la cross-compilation serait peut-être suffisante. Mais dès lors que quelque chose ne fonctionne pas comme attendu, ce n'est pas le programmeur "Métier" qui entre en jeu (celui qui développe le projet)... mais le programmeur de composants ('le Technos')... quand il le veut (ou quand il le peut) puisque ce n'est pas bloquant pour son alter ego. C'est le cas de le dire ici, puisqu'il s'agit dans mon cas de la même personne. Le Technos utilise nécessairement la version de Lazarus sur l'OS qui pose problème. Souvent l'analyse du code de Lazarus est nécessaire, le debugger aussi. Des fois le Technos en a marre, ou le programmeur "Métier" manque d'inspiration...
Tiens ! Le EndEllipsis ne fonctionne pas sous Nux dans la TStringGrid ? Je note au moment du test... et le Technos, quelques jours plus tard, dans un trou de son emploi du temps, s'y colle : conclusion le code n'est valable que pour Windows... Il modifie la TlzStringGrid et le programmeur Métier n'a qu'à remettre à jour la version de ce composant... sans rien changer d'autre. Tiens ? un binary de la base PostGreSQL ne peut pas être stocké dans une cellule d'une TStringGrid pour être traduit en image dans une autre cellule ?... A traiter. Etc... Je trouve pour cela Lazarus fabuleux -sans exagérer- et sans aucun autre équivalent... même si je le déplore.
Bonne fin de WE.
Cordialement. Gilles
*les 10% c'est principalement l'encodage natif UTF8 ou non des OS donc la nécessaire utilisation d'UTF8ToAnsi ou vice versa et autres soucis du même genre.
PS : Petit commentaire pour l'installation de Lazarus sur Mac OS X
Dernière modification par Invité ; 27/01/2013 à 12h22. Motif: Principalement orthographe.
Bonjour à tous,
et merci Selzig pour ta réponse longue et détaillée.
En ce uqi concerne FMX, j'arrive à faire pas mal de choses snas trop ramer, je veux dire les trucs de base. La cross-compilation fonctionne assez bien quand on a compris le principe (genre ça ne fonctionne que si ton MAC et ton XP sont sur un réseau IP, donc pas possible si tu as une VM XP sur le MAC, et que tu es quelque part snas Internet, car pas d'@IP, donc pas de comm possible entre Delphi et le PServer...).
Ensuite pour les composants, ça marche sans trop de soucis, le concept fonctionne bien. Beaucoup mieux que la librairie FMX qui est blindée de bugs (on dirait un soft à moi...
A noter aussi une arborescence des objets visuels assez particulière, qui font que certaines choses deviennent assez tordues. Bref, pas facile. Et la doc (non je ne blague aps y en a mais tellement peu) est d'une qualité et d'une quantité exécrable...
Certains objets visuels fonctionnenet différemment, les TGrids par exemple qui ont un fonctionnement... logique mais "so different"...
Et pour avoir une version un peu plus stable, faut redébourser 1000€ poru XE3, une vraie honte.
Du coup, je me pose sincèrement la question de Lazarus qui avec la version 1.0.2 (enfin on arrive à une version majeure) devrait être un peu plus stable.
En ce qui me concerne, je n'ai pas le temps (ni les compétences) de corriger les objets visuels, je devrai donc m'en tenir aux choses de base. En même temps, je développe pour moi, sans BDD ni trucs de la mort qui tue, juste lire/écrire des ficheirs XML en UTF-8, générer du PDF (encore impossible avec FMX), éventuellement du XLSX (via une lib EXCELLENTE de Ondrej Pokorny (http://kluug.net)) donc une install de base devrait suffir.
Là où la cross compli m'intéresse, ça serait pour éviter d'installer 2 fois Lazarus juste pour compiler. Donc je vais continuer (ou plutôt commencer) à regarder Lazarus de plus préès, je devrai juste refaire toute la partie GUI de mon appli (c'est aps la partie la plus complexe d'aillleurs...).
Bravo à toi pour le travail que tu fais et surtout pour els avis éclairés et motivés !
En fait, parce que j'ai aps l'impression d'avoir bien compris.
FMX gère ses composants visuels afin qu'ils soient multi plateforme (il redessine tout, gère tout et tout et tout).
VCL s'appuis sur les contrôles et mécaniques Windows, ce qui la rend inutilisable en dehors de Windows.
Lazarus dispose-t-il d'un équivalent FMX ? Si oui c'est stable, propre ?
En fait ca sera mon premier point important...
Bonjour,
je ne sais suffisamment pas comment fonctionne FMX. C'est d'ailleurs certainement pour cela que j'y perds mon latin.
"Sous" Lazarus, il y a fpGui qui est indépendant des OS : il utilise et dessine ses propres widgets : http://fpgui.sourceforge.net/screenshots_widgets.shtml
Il existe même un concepteur visuel de Form : http://fpgui.sourceforge.net/screenshots_apps.shtml.
Mais l'intégration dans l'IDE Lazarus est "spartiate".
Un autre problème est l'absence de communauté et même si je trouve ce travail vraiment intéressant, il me semble maintenu et développé par une seule personne. Ce n'est visiblement pas la voie officielle retenue mais plutôt un travail de "recherche". Je ne dis pas que c'est la bonne voie mais quand on lit le bugtracker de Lazarus/FPC, le nombre de bugs relatifs à FP est ridicule comparé à celui de Lazarus et parmi ces derniers le nombre de bugs relatifs aux composants graphiques est très majoritaire. Par contre, sous fpGui, les widgets (donc les composants graphiques) sont moins élaborés que ceux de Lazarus qui eux-mêmes sont souvent loin de la richesse des composants additionnels réalisés par les Delphiens. Le tout est d'estimer là-encore, s'il s'agit d'une chimère ou non.
Cordialement. Gilles
Dernière modification par Invité ; 28/01/2013 à 14h10.
Merci pour les infos.
En fait une question qui me taraude : la librairie équivalente de VCL, si je fais un soft qui l'utilise, ca se compilera aussi sur OSX ou pas ?
Et pour répondre à ta question sur FMX, c'est une librairie qui permet de développer des applis multi plateforme. Donc le contrôle bouton n'utilise pas l'API Windows, au lieu de ça FMX réécrit tout (affichage, gestion du clavier et de la souris...). En plus FMX ajoute beaucoup de choses qui n'existaient pas dans la VCL :
- gestion des styles
- boutons et Edit avec coins arrondis
- container intelligent (n'importe quel objet visuel peut être parent d'un autre contrôle. Pas facile à manipuler mais terriblement efficace pour la conception)
- dessin 2d et 3d (perso pas d'utilité)
- rotation d'un contrôle
- unification de la propriété "Text" et "Caption" en Text : plus simple
- une rationalisation de certains contrôles : pas simple à comprendre mais quand on a compris, c'est pas mal
- meilleure gestion du modèle Vue-Donées-Contrôle (pas simple non plus mais logique)
- liaison de données
- DataSnap
- Et j'en passe...
PAr contre certaine choses sont déroutantes au début. Après c'est comme le vélo, on s'y fait. Ou pas...
Et il reste une tétra-chiée de bugs dans FMX 2 (achetez la version 3 pour du plus stable).
Et surtotu presque pas de docs, et ça c'est honteux ! Au mions Lazarus est presque sans docs non plus, mais on n'a pas payé !
Pour la LCL considérée sous l'angle de l'équivalent de la VCL, il vaut mieux en parler à un Delphien/Lazarusien. Mes connaissances s'arrêtent à Delphi 7 et un petit peu à Kylix... Une antiquité quoi !
Pour la LCL elle-même ("hors" équivalence), vous avez un début de réponse. Lazarus l'utilise lui-même. Et l'IDE Lazarus fonctionne sous Win32, 64, Linux 32, 64, Mac Os 32. C'est quand même un gage de "faisabilité"...
Bonne fin de journée. Gilles
Dernière modification par Invité ; 28/01/2013 à 14h37.
forcément présenté comme ça...
Je savais que Lazarus était écrit en Pascal et compilé grâce à FPC, mais je ne savais pas que Lazarus était écrit avec la LCL...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager