Discussion :

[Yogui]

<derive>
A ce sujet ==>

Ils en sont ou de http://pecl4win.php.net/ ? Car c'est très embêtant cette situation..
</derive>

Ce n'est pas une dérive, tu fais bien de poser la question et c'est un problème épineux.

Je rappelle ce qu'il en est pour tout le monde

PHP jusqu'à la branche 5.2 était compilé avec Microsoft Visual C++ 6, un outil qui n'est plus disponible sur le marché. Il n'est donc plus possible de continuer avec VC6.

Cependant, la quasi totalité des projets open source sont compilés avec cet outil encore aujourd'hui. Ils ont l'avantage d'avoir des "build box" qui fonctionnent encore, ce qui n'est plus le cas de PHP. Le projet PHP a eu le malheur de voir partir "la" personne qui savait comment fonctionnait la machine de pecl4win... Plus personne ne sait comment la configurer, il a donc été décidé de l'arrêter.

De toute manière, VC6 est... Vieux. Il était grand temps de passer à une nouvelle version du compilateur et de pousser les autres projets open source à faire de même.

La nouvelle optique est de compiler à l'aide de Visual Studio 2008, aka VC9.

Le problème est que les fichiers binaires compilés sous VC9 ont besoin de DLL compilées avec la même version du compilateur, à savoir que l'on ne peut pas utiliser une extension PHP compilée avec VC6, pour un PHP compilé avec VC9. De même, Apache doit lui aussi être compilé avec le même outil que le reste. Lorsqu'il s'agit de mod_php, toute la chaîne doit être compilée avec le même outil. En mode CGI ou FastCGI c'est différent, Apache et PHP peuvent être compilés différemment mais les extensions doivent néanmoins correspondre à la signature du binaire PHP... Donc le problème reste entier.

Bien entendu, compiler PHP lui-même sous VC9 n'est pas un problème. Il y a de nombreux tutos pour le faire, en voici un exemple : http://wiki.php.net/internals/windows/stepbystepbuild
Pour Apache : http://fabien-faille.developpez.com/...dows-compiler/

Mais pour compiler PHP, il faut s'assurer que toutes ses dépendances soient aussi compatibles VC9 : http://wiki.php.net/internals/windows/libs
Il en va de même pour chacune des extensions "core" et de chacune des extensions "PECL".

Chaque extension utilisant une bibliothèque externe doit aussi compiler ces dépendances avec VC9, ce qui suppose de prendre contact avec l'auteur de chacune de ces dépendances afin qu'il mette son projet à jour.

La liste complète des dépendances est disponible ici avec un état des lieux : http://wiki.php.net/internals/windows/libs
La liste complète des dépendances qui ont pu être migrées est disponible ici : http://pecl2.php.net/downloads/php-w...ilds/php-libs/


Cela vous donne une idée de l'énorme quantité de travail faite par la nouvelle équipe de compilation de PHP pour Windows (Pierre, Elizabeth, Garrett et les autres) simplement pour "PHP core".

Yapukà faire "PECL"


Informations liées :
http://blog.developpez.com/julienpau...pache-softwar/
http://blog.developpez.com/web/p5272...dependances-s/
http://blog.developpez.com/web/p6152...ie-de-php-5-3/

[kaymak]

argh damn it ! J'espère qu'ils vont y arriver le problème à l'air terrible sur le papier.....

Dommage pour moi autrement, je vais devoir passer les postes de travail sous ubuntu si je veux avoir un peu de flexibilité (ce n'est pas moi que cela déranges ; ), mais bon va falloir tout leur ré expliquer... :-x c'est pas gagné.


a plus, merci de l'info yogui

[Yogui]

Il y a ici des liens que je ne connaissais pas : http://downloads.php.net/pierre/

[kaymak]

Il y a ici des liens que je ne connaissais pas : http://downloads.php.net/pierre/

Ouah super le lien ! Je vais me tester cela mais il y à toutes les libs qu'ils me manquaient memcache, apc et xdebug. Trop fort.

[Yogui]

J'ai eu des problèmes avec la version compilée avec VC9 (cf. les explications plus haut). En revanche, si tu prends un apache-vc9, il n'y a plus de problème

[Yogui]

Salut

Je me suis mélangé les pinceaux dans mon message précédent, c'est avec la version VC6 que j'avais des problèmes.

Concernant ton problème, tu as deux solutions :

• Soit tu attends que wamp et les autres outils similaires (en particulier celui que tu utilises) se mettent à supporter PHP 5.3
• Soit tu installes toi-même un serveur Apache + PHP 5.3 en version VC9.

[aityahia]

n'y a t'il donc pas moyen d'utiliser php 5.3 sur wamp, easyphp ou un autre environnement wamp "tout-en-un" ?
faut-il obligatoirement passer par IIS ou autre gros truc du genre ?

Oui, mais ça risque d'être instable.

Zend Server Early Access for PHP 5.3

[metagoto]

j'ai pris la version compilé avec VC6 car je pense que wampserver utilise les applications compilés avec VC6..

en fait, je voudrais pouvoir utiliser php 5.3 en local, et si possible dans un environnement léger (c'est pour ça que j'utilise wampserver).

n'y a t'il donc pas moyen d'utiliser php 5.3 sur wamp, easyphp ou un autre environnement wamp "tout-en-un" ?
faut-il obligatoirement passer par IIS ou autre gros truc du genre ?

Essaie peut être de faire tourner php en fastcgi plutôt qu'en tant que module d'apache. Il te faut activer mod_fastcgi puis le configurer pour aller charger ton php-cgi.exe. Je n'ai plus tous les détails en tête (je n'utilise pas apache).
Le premier lien trouvé (en anglais) :
http://journal.suteki.nu/2009/02/18/...gi-on-windows/

Sous Windows, je préfère installer tous les composants WAMP (ou équivalent) à la main. C'est pas plus compliqué que d'installer un package tout fait comme WAMP Server. L'avantage, c'est qu'on peut upgrader chaque composant indépendamment du reste et, avant tout, c'est un bon moyen de comprendre comment tout ceci fonctionne.

[Shirraz]

PHP jusqu'à la branche 5.2 était compilé avec Microsoft Visual C++ 6, un outil qui n'est plus disponible sur le marché. Il n'est donc plus possible de continuer avec VC6.

Cependant, la quasi totalité des projets open source sont compilés avec cet outil encore aujourd'hui.

HS, mais je trouve ça "drôle", pour les fans du tout open source qui crache sur "M$" à longueur de journée comme le diable à bannir...

[metagoto]

HS, mais je trouve ça "drôle", pour les fans du tout open source qui crache sur "M$" à longueur de journée comme le diable à bannir...

Dans le post précédent de Yogui, il faut comprendre qu'il s'agit des projets open source portés sur Windows. Ces derniers étant généralement développés sous *nix et compilés avec gcc.

[Yogui]

Dans le post précédent de Yogui, il faut comprendre qu'il s'agit des projets open source portés sur Windows. Ces derniers étant généralement développés sous *nix et compilés avec gcc.

Mon message était incomplet. Il s'agit en effet des projets portés sous Windows et surtout, il manquait la mention suivante : les projets sont souvent disponibles pour plusieurs compilateurs, dont cygwin et Visual Studio. Seulement, tous les projets ne proposant pas ces multiples versions, le projet PHP a été contraint de faire le choix de prendre celui qui est le plus fréquent : VS.

Il serait absurde de compiler systématiquement avec cygwin simplement parce que c'est "pur open source", tu ne crois pas ?

De plus, objectivement, si Visual Studio est plus efficace pour un target Windows : pourquoi s'en priver ?

[gannher]

J'apprécie beaucoup les tableaux à taille fixe ( SplFixedArray ).
Par contre je n'ai toujours pas compris les espaces de noms (namespace). Je ne comprends pas leur utilité et je n'arrive pas à m'imaginer un cas concret.

[kaymak]

Les espaces de noms te sont utile pour créer des contextes de nommage restreint dans le contexte d'exécution global.
Dans ce contexte restreint, tu vas pouvoir re déclarer toutes les classes que tu avais déclarés dans le contexte global, et les utiliser indépendamment ou conjointement avec les classes du contexte global.
Sans pour autant créer de collisions.

en large.

M'enfin qd tu auras un certains nombre de classes dans ton appli tu en comprendra le sens car cela deviendra un besoin, d'ici là réjouis toi de ne pas en avoir usage parce que le backslash, en ce qui me concerne à encore du mal à passer :\

[gannher]

Ah alors ce n'est utile que pour les très gros projets ?
Parce que même dans un framework par exemple, je n'en vois pas encore l'utilité.
Je suis en train de faire mon propre framework en php et j'ai beau réfléchir, je ne croule pas encore sous le nombre de classes ^^ .

L'utilisation des espaces de nom doit se limiter pour les gros projets métiers sans doute.

[berceker united]

Ah alors ce n'est utile que pour les très gros projets ?
Parce que même dans un framework par exemple, je n'en vois pas encore l'utilité.
Je suis en train de faire mon propre framework en php et j'ai beau réfléchir, je ne croule pas encore sous le nombre de classes ^^ .

L'utilisation des espaces de nom doit se limiter pour les gros projets métiers sans doute.

Non, c'est tout aussi utile dans une framework et je dirais même que c'est là ou c'est le plus utilisé.

[kaymak]

L'utilisation des espaces de nom doit se limiter pour les gros projets métiers sans doute.

tu peux le comprendre ainsi. Je me serait contenté d'un, passé un nombre de classe n (c'est un n subjectif^^), les espaces de noms sont les bienvenues.

Après, libre à toi d'utiliser les espaces de noms (ou une convention de nommage), quelque soit le nombre de tes classes.

Cela peut t'aider à mieux organiser ton projet.

[metagoto]

L'utilisation des espaces de nom doit se limiter pour les gros projets métiers sans doute.

Je n'irai pas jusque là. A mon avis, dès qu'un projet, aussi petit soit-il, est succeptible de manipuler différents composants provenant de différentes sources, alors les espaces de noms sont conseillés.

Dans la pratique, les auteurs de libraries ont pris l'habitude de préfixer leurs classes et fonctions de manière à "émuler" un espace de nom qui leur est propre. Genre Zend_Blah, sfBlah...

Maintenant, avec php 5.3, on devrait théoriquement se passer de ses préfixes archaïques en utilisant, au minimum, un niveau d'espace de nom: Zend\, sf\ (ou symfony\) etc.

[berceker united]

Un peut le même débat entre le faite de spécifier ou non le type d'accès à un élément d'une classe, je parle des Private Public ou Protected.

[kaymak]

en tout cas php5.3, je ne sais pas si vous y etes passé, mais toutes mes signatures de méthodes surchargées ( redéfinies dans une sous-classe) ne sont plus valables parce qu'elles différent d'un argument ou deux....

Donc pour le moment bof bof là qd mm, sa soul même.

[berceker united]

en tout cas php5.3, je ne sais pas si vous y etes passé, mais toutes mes signatures de méthodes surchargées ( redéfinies dans une sous-classe) ne sont plus valables parce qu'elles différent d'un argument ou deux....

Donc pour le moment bof bof là qd mm, sa soul même.

Tu as surchargé une méthode d'une classe parente avec une différence de signature ? Quel est le message d'erreur exactement. Il dit que tu as une différence du nombre de paramètre par rapport à la méthode que tu surcharges ? Tu n'as pas déclarer une interface quelque part ?