J’ai écrit un petit script shell (qui peut être grandement amélioré, tout aide est bienvenue) pour la création d’un installateur Windows des EFL. Les instructions se trouvent sur le wiki.
L’installateur contiendra le code des EFL récupéré du trunk (donc les derniers sources).
Toute idée, critique ou remarque est bienvenue
Bonjour,
En essayant le script, j’obtiens lors de la compilation d’eina:
‘In file included from /home/alex/Devel/efl_installer/efl/include/evil-1/Evil.h:130:0,
from eina_log.c:40:
/home/alex/Devel/efl_installer/efl/include/evil-1/evil_time.h:34:17: error: expected identifier or ‘(‘ before ‘{‘ token’
As tu une idée? Evil semble bel et bien compilé, j’obtiens les bon binaires(test_evil.exe…) qui fonctionnent bien avec wine et surtout le header evil_time semble correct, j’ai comme l’impression que quelque chose est mal passée…
Autre chose, Petite typo dans la doc sur le wiki, tu indiques PROTO/evil or evil se situe dans le trunk. :-) pourquoi quitter le script si l’on ne possède pas makensis? ça peut-être intéressant de ne pas souhaiter créer un installeur…
Et pour terminer, qu’elle est le but de la librairie Exotic? remplacera t’elle à terme Evil? sont elle redondantes?
En tout les cas merci pour ce script!
1) pour l’erreur, je ne vois pas. Il n’y a pas 36 problèmes, néanmoins. Il y a EAPI (mais lui devrait être bon), struct tm et time_t.
tu pourrais faire un grep dans le répertoire de mingw-w64 pour ‘struct tm’ et ‘time_t’ et voir dans quels fichier(s) ils sont ?
2) typo : corrigée, merci
3) pour NSIS, honnêtement, je suis nul en scripts shell et j’ai fait cet installateur à l’arrache. On peut rajouter des options, bien sûr. On pourrait faire un installateur, des archives, etc… Toute idée et patch est le bienvenu
4) exotic devrait etre une unique lib pour une implementation d’une helper lib comme evil, pour 3 plateformes : windows, ps3 et coyotte. Donc normalement, oui, elle devrait remplacer Evil, même si j’aimerais bien garder Evil pour le nom de cette lib.
Bonjour,
J’ai avancé sur la fameuse erreur, localtime_r est déjà définit dans time.h(w64-mingw32-gcc-4.6.4 cross compilation sous linux). Visiblement c’est une macro
:
#ifndef localtime_r
#define localtime_r(_Time, _Tm) ({ struct tm *___tmp_tm = \
localtime((_Time)); \
if (___tmp_tm) { \
*(_Tm) = *___tmp_tm; \
___tmp_tm = (_Tm); \
} \
___tmp_tm; })
#endif
Pour le script, hélas je ne suis pas non plus un dieu du shell-scripting, j’ai juste ajouté comme modif sur ton script( pour m’aider à vérifier ma configuration):
echo « Environnement settings: »
echo
echo export CPPFLAGS=\ »$CPPFLAGS\ »
echo export LDFLAGS=\ »$LDFLAGS\ »
echo export PATH=\ »$PATH\ »
echo export LD_LIBRARY_PATH=\ »$LD_LIBRARY_PATH\ »
echo export PKG_CONFIG_PATH=\ »$PKG_CONFIG_PATH\ »
echo export PKG_CONFIG_LIBDIR=\ »$PKG_CONFIG_LIBDIR\ »
echo
echo » Windows installer……………..: ${_success} »
echo
en prenant soin de désactiver l’exit quand makensis n’est pas dispo…
je viens de faire un commit dans le svn pour le bug. Merci :-) Tu peux tester, ca devrait etre bon.
je vais mettre a jour le script durant les prochains jours
Merci encore
Cool! merci pour ta réactivité! :-)
D’autres problèmes apparaissent, pour la crosscompilation sous Linux:
=>L’archive w64-mingw32-gcc-4.6.4 que tu proposes en téléchargement à des problèmes avec freetype: freetype/config/ftheader.h pointe sur freetype mais ce répertoire n’existe pas? il faudrait déplacer le contenu de include/freetype2/freetype/* dans include/freetype2 et créer un lien de include/freetype vers freetype2/
=>Evas:Avec le script shell, et si l’on utilise toujours l’archive citée au dessus, il compile par défaut le moteur direct3d(les headers sont présents). Peut-être ajouter l’option –disable-direct3d par défaut, dans le script, serait une bonne option?
=>Mettre à jour le wiki pour les options Ecore:
–disable-glib –enable-win32-threads=yes –enable-cares -disable-gnutls –disable-openssl
=>Ecore: si l’on active –enable-build-examples, la fonction fork() n’est pas définie, peut-être manque t’il un #ifdef WIN32?
=>Elementary: fonction strcasestr non définie, apparement c’est une extension GNU. Peut-être l’implémenter dans evil?
=>Elementary:le théme ne compile pas avec embryo_cc, en fait il n’existe pas de fonction comme –embryo-cc=/usr/local/bin/embryo_cc…a noter que ce problème existe aussi pour edje lorsque l’on utilise –enable-build-examples.
A part tout ceci, j’ai réussi à cross-compilé sous Linux. Il me manque juste elementary et ce satané thème qui bloque l’installation compléte(pkgconfig…).
Beau travail!
pour freetype, bizarre. Ici aucun probleme. Je verifierai
evas : c’est fait en local
ecore : j’ai corrigé le wiki
ecore et fork : il faudrait faire un autre code
elementary et strcasestr : bizarre, ca compile ici. Je regarderai
elementary et theme : embryo_cc doit etre dans le path. il est appele par edje_cc avec un appel à system()
merci !
Autant pour moi pour embryo_cc, tout est ok!
Existe t’il un exemple pour compiler avec les autotools (ou toi même possèdes tu) et sous mingw32 en utilisant la librarie elementary? j’obtiens le message borné suivant:
/home/alex/Devel/efl/frilogos/src/bin/frilogos.c:354: undefined reference to `__imp__elm_main’
Le wiki indique bel et bien une procèdure pour compiler une librarie sous mingw32:
http://trac.enlightenment.org/e/wiki/AutotoolsIntegration
Mais quid d’une application liée à elementary-win32?
As tu entendu parlé de ce projet?
http://gnuwin32.sourceforge.net/packages/libgw32c.htm
J’ai vu qu’ils avaient une implémentation de fork pour win32…mais j’imagine que tu as déjà fait le tour de la question…
Merci.
Il y en a un : elementary_test :-)
Mais un petit exemple, la non. Il faut bien linker contre la lib d’elementary. Là il me faut plus de précisions. Si tu peux fournir l’archive, je peux regarder. En tout cas, je sais que ça marche.
Concernant le projet gnuwin32, je connais, et il est mort. Quant au fork, j’ai fait le tour de la question et la réponse est simple : ca n’existe pas sous Windows. Il existe une implémentation qui reproduit un peu le même comportement que le fork d’unix, mais ça utilise des fonction du noyau non documentées et le comportement étant un peu différent, cette implémentation ne peut pas être utilisée telle quelle. Ce que l’on fait en général est : fork+exec == CreateProcess ou CreateThread,en fonction du contexte.
Bonjour,
J’ai mis les sources de mon projet posant problème avec la compilation mingw32:
http://dl.free.fr/rR6hT7UpG
Je t’ai aussi envoyé un lien pointant sur celui-ci, mais parfois les mails de free finissent aux indésirables.
En ce moment même, je pars d’une base toute simple(simple binaire sans lib) pour tenter de compiler sous mingw32 avec elementary…
Voilà!après une bonne quantité d’essais je viens de -comprendre-trouver- la solution:
EAPI elm_main(int argc, char **argv)
doit être déclaré comme:
EAPI_MAIN int elm_main(int argc, char **argv)
du coup tout fonctionne au poil! j’ai mon projet fonctionnant sous Windows et Linux! Autre détail important, j’ignore ce que tu as fais mais il n’est plus indispensable d’activer la compatibilité avec Windows XP sous Windows 7.
Tu peux aussi mettre à jour le wiki, plus besoin d’exporter engine=gdi, tout se fait automatiquement :-)
hmmm, ce n’est pas parce que tu as fais un export de ELM_ENGINE précédemment, et que elementary l’a conservé dans sa config ? (ou un truc comme ca)
en fait, non, elm essaie tous les engine possibles
Je viens d’ajouter strcasestr() à Evil. Ca a été ajouté récemment.
Je pense que j’ai tout regardé à part le package Freetype
le package freetype est bon. J’ai installé les headers dans les bons repertoires