Re: [Avr-list] probleme de make sous dos, des déta ils...

2008-02-20 Par sujet tof
j'utilise winavr


j ai aussi cygwin d'installe, mais je fais gaffe qu'il ne soit pas 
present dans le PATH dos


Benoît Ryder a écrit :
 C'est quelle version de bash/sh que vous utilisez sous Windows ?
 Sur l'installation que j'ai de msys, j'ai pwd comme builtin function de
 bash/sh mais pas de pwd.exe, du coup les deux me retourne la même
 chose (des chemins de la forme /d/toto/).

   
 Ou bien trouver un moyen de 
 ne pas le faire sous windows : par exemple utiliser une variable 
 d'environnement qui dit sous quel OS on est (y'en a-t-il une ?). Si 
 quelqu'un a le temps de regarder s'il y a une variable qui serait 
 OS-dependant.
 
 Sous Windows y'a $OS = Windows_NT, y'a pas sous Linux à ma connaissance.

 ~ryder


 ___
 Avr-list mailing list
 Avr-list@droids-corp.org
 CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
 WIKI : http://wiki.droids-corp.org/index.php/Aversive
 DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
 BUGZILLA : http://bugzilla.droids-corp.org
 COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog

   


___
Avr-list mailing list
Avr-list@droids-corp.org
CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog


[Avr-list] probleme de make sous dos, des déta ils...

2008-02-17 Par sujet tof



Acte 1 :

je regarde ce que sortent les 2 lignes suivantes :
ABS_AVERSIVE_DIR:=$(shell cd $(AVERSIVE_DIR) ; pwd)
ABS_PROJECT_DIR:=$(shell pwd)

j utilise un print du genre :
   @echo ABS_AVERSIVE_DIR =  $(ABS_AVERSIVE_DIR)
   @echo ABS_PROJECT_DIR =  $(ABS_PROJECT_DIR)


j'obtiens :

sous cygwin :
 ABS_AVERSIVE_DIR = /cygdrive/d/projets/avr/aversive
 ABS_PROJECT_DIR = /cygdrive/d/projets/avr/aversive/modules/comm/uart/test

sous dos :
 ABS_AVERSIVE_DIR = /d/projets/avr/aversive
 ABS_PROJECT_DIR = D:\projetsvrversive\modulesomm\uart   est


cygwin fait sa sauce, tant pis, on a pass besoin de faire fonctionner 
sous cygwin (recompil de avr-gcc et consorts fonctionnera).
pour le dos, c'est très bizarre, le pwd renvoie un path formaté 
différamment  dans les 2 cas!!
en plus les \ sont interpretes comme caracteres d echappement et mettent 
le bronx un peu partout dans la suite du makefile

(cela arriverait il aussi sous linux avec un path contenant des espaces ?)


Acte 2 :

après pas mal de tests, je remarque des différences en executant le pwd 
ou pwd.exe (qui renvoie pourtant au même fichier !) il doit executer 
dans un contexte différent si on ajoute .exe : (shell dos)


D:\projets\avr\aversive_head\modules\comm\uart\testsh -c 'cd . ; pwd.exe'
D:\projets\avr\aversive_head\modules\comm\uart\test

D:\projets\avr\aversive_head\modules\comm\uart\testsh -c 'cd . ; pwd'
/d/projets/avr/aversive_head/modules/comm/uart/test



Acte 3 :


je change la ligne :
ABS_PROJECT_DIR:=$(shell pwd)
en :
ABS_PROJECT_DIR:=$(shell cd . ; pwd)

les variables sortent comme ca :
 ABS_AVERSIVE_DIR = /d/projets/avr/aversive
 ABS_PROJECT_DIR = /d/projets/avr/aversive/modules/comm/uart/test


deja un net progres : on a le meme format. Le pourquoi est assez 
inexpliqué. probablement le make execute t il le pwd dans un contexte 
différent

(sh ou dos)

manque de bol, le reste du makefile ne fonctionne quand meme pas.


Acte 4 :

Probleme : Avr-gcc et autres ne prennent en compte que les chemins du 
type dos natif (bizarre aussi ) :



D:\projets\avr\aversive\modules\comm\uart\testsh -c avr-gcc -M -g -O3 
-Wall -W
strict-prototypes -I. -I/d/projets/avr/aversive/include 
-I/d/projets/avr/aversiv
e/modules -I/d/projets/avr/aversive/modules/base/utils 
-I/d/projets/avr/aversive
/modules/base/wait -I/d/projets/avr/aversive/modules/base/list 
-std=gnu99 -funsi
gned-char -funsigned-bitfields -fpack-struct -fshort-enums 
-mmcu=atmega128 main.

c
# 1 D:\\projets\\avr\\aversive\\modules\\comm\\uart\\test//
main.o: main.c \
 c:/winavr/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/stdio.h \
 c:/winavr/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/inttypes.h \
 c:/winavr/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/stdint.h \
 c:/winavr/bin/../lib/gcc/avr/3.4.3/include/stdarg.h \
 c:/winavr/bin/../lib/gcc/avr/3.4.3/include/stddef.h \
 c:/winavr/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/avr/io.h \
 
c:/winavr/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/avr/sfr_defs.h \

 c:/winavr/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/avr/iom128.h \
 
c:/winavr/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/avr/portpins.h \

 c:/winavr/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/avr/pgmspace.h




gcc ne prend pas cettte forme pour le fichier d'entrée :

marche pas :
D:\projets\avr\aversive\modules\comm\uart\test avr-gcc -c -g  -O3 -Wall 
-Wstrict-prototypes -I. 
/d/projets/avr/aversive/modules/comm/uart/test/main.c -o 
compiler_files/main.avr.o
avr-gcc: /d/projets/avr/aversive/modules/comm/uart/test/main.c: No such 
file or

directory

marche pas :
D:\projets\avr\aversive\modules\comm\uart\testavr-gcc -c -g  -O3 -Wall 
-Wstrict
-prototypes -I. d:/projets/avr/aversive/modules/comm/uart/test/main.c -o 
compile

r_files/main.avr.o

marche :
D:\projets\avr\aversive\modules\comm\uart\testsh -c avr-gcc -c -g  -O3 
-Wall -
Wstrict-prototypes -I. 
/d/projets/avr/aversive/modules/comm/uart/test/main.c -o

compiler_files/main.avr.o



on dirait que gcc depend fortement du contexte dans lequel il est 
executé (dos ou sh), comme pwd




Acte 5 :

j ai fait un tet pour convertir dans le format accepté par gcc :  c://

ABS_AVERSIVE_DIR:=$(shell cd $(AVERSIVE_DIR) ; pwd.exe | sed 's__/_g')
ABS_PROJECT_DIR:=$(shell cd . ;  pwd.exe | sed 's__/_g')


le makefile arrive au bout sans encombre !!

comment ca, de la bidouille ?? bon OK, d'accord...

Acte 6 :

et si on essayait de faire sh -c make au lieu de make
ben non , ca ne donne rien (voir PJ)
par contre, il y a quelques différences, genre la facon dont le 
sous-make est appelé (avec un .exe sous sh seulement !!)


Conclusion :

- le make executerait semble t il les sous programmes dans des 
environnement différents selon pas mal de cas. il faudrait pouvoir 
forcer les programmes appelés a s'exec sous sh

- l'environnement fait toute la différence (rien a voir avec l'écologie)


on peut faire quoi ?






D:\projets\avr\aversive_head\modules\comm\uart\testsh -c make