je voudrais utiliser un soft écrit en ObjC (seticon pour MacOS X) avec
un wrapper de ce soft écrit en C pour Ruby (language de script) et
ainsi bénéficier d'une extension Ruby.
j'ai testé mon C (en "squelette") et aussi seticon en ObjC mais je
n'arrive pas à les compiler ensemble, j'obtiens une "tétrachiée"
d'erreurs à cause des @ qui sont dans les .h et autres .m d'ObjC.
j'imagine qu'il y a une directive gcc pour permettre ce mixage ???
pour info j'utilise mkmf de Ruby pour générer le Makefile.
ou bien, dois-je compiler séparément est ajouter après coup les .o
d'ObjC dans mon .bundle ???
je ne connais pas du tout ce genre de manip...
si vous avez un peu de lumière...
je voudrais utiliser un soft écrit en ObjC (seticon pour MacOS X) avec
un wrapper de ce soft écrit en C pour Ruby (language de script) et
ainsi bénéficier d'une extension Ruby.
j'ai testé mon C (en "squelette") et aussi seticon en ObjC mais je
n'arrive pas à les compiler ensemble, j'obtiens une "tétrachiée"
d'erreurs à cause des @ qui sont dans les .h et autres .m d'ObjC.
j'imagine qu'il y a une directive gcc pour permettre ce mixage ???
pour info j'utilise mkmf de Ruby pour générer le Makefile.
ou bien, dois-je compiler séparément est ajouter après coup les .o
d'ObjC dans mon .bundle ???
je ne connais pas du tout ce genre de manip...
si vous avez un peu de lumière...
je voudrais utiliser un soft écrit en ObjC (seticon pour MacOS X) avec
un wrapper de ce soft écrit en C pour Ruby (language de script) et
ainsi bénéficier d'une extension Ruby.
j'ai testé mon C (en "squelette") et aussi seticon en ObjC mais je
n'arrive pas à les compiler ensemble, j'obtiens une "tétrachiée"
d'erreurs à cause des @ qui sont dans les .h et autres .m d'ObjC.
j'imagine qu'il y a une directive gcc pour permettre ce mixage ???
pour info j'utilise mkmf de Ruby pour générer le Makefile.
ou bien, dois-je compiler séparément est ajouter après coup les .o
d'ObjC dans mon .bundle ???
je ne connais pas du tout ce genre de manip...
si vous avez un peu de lumière...
Contrairement à C++, les fonctions en Objective-C sont des fonctions C
normales. Donc il faut compiler la bibliothèque avec le compilateur
Objective-C, et faire l'édition de lien avec ruby comme si c'était du
C (c'est du C!).
-----(MyObj.m)---------
@implementation MyObj
- myMethod:(int)a
{
return [self ragnagna:(a+1)];
}
@end
id MyObj_myMethod(id obj,int a){
return [obj myMethod:a];
}
------------------------
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
Contrairement à C++, les fonctions en Objective-C sont des fonctions C
normales. Donc il faut compiler la bibliothèque avec le compilateur
Objective-C, et faire l'édition de lien avec ruby comme si c'était du
C (c'est du C!).
-----(MyObj.m)---------
@implementation MyObj
- myMethod:(int)a
{
return [self ragnagna:(a+1)];
}
@end
id MyObj_myMethod(id obj,int a){
return [obj myMethod:a];
}
------------------------
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
Contrairement à C++, les fonctions en Objective-C sont des fonctions C
normales. Donc il faut compiler la bibliothèque avec le compilateur
Objective-C, et faire l'édition de lien avec ruby comme si c'était du
C (c'est du C!).
-----(MyObj.m)---------
@implementation MyObj
- myMethod:(int)a
{
return [self ragnagna:(a+1)];
}
@end
id MyObj_myMethod(id obj,int a){
return [obj myMethod:a];
}
------------------------
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
On 8 août, 22:22, Pascal Bourguignon wrote:Contrairement à C++, les fonctions en Objective-C sont des fonctions C
normales. Donc il faut compiler la bibliothèque avec le compilateur
Objective-C, et faire l'édition de lien avec ruby comme si c'était du
C (c'est du C!).
-----(MyObj.m)---------
@implementation MyObj
- myMethod:(int)a
{
return [self ragnagna:(a+1)];
}
@end
id MyObj_myMethod(id obj,int a){
return [obj myMethod:a];
}
------------------------
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape...
On 8 août, 22:22, Pascal Bourguignon <p...@informatimago.com> wrote:
Contrairement à C++, les fonctions en Objective-C sont des fonctions C
normales. Donc il faut compiler la bibliothèque avec le compilateur
Objective-C, et faire l'édition de lien avec ruby comme si c'était du
C (c'est du C!).
-----(MyObj.m)---------
@implementation MyObj
- myMethod:(int)a
{
return [self ragnagna:(a+1)];
}
@end
id MyObj_myMethod(id obj,int a){
return [obj myMethod:a];
}
------------------------
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape...
On 8 août, 22:22, Pascal Bourguignon wrote:Contrairement à C++, les fonctions en Objective-C sont des fonctions C
normales. Donc il faut compiler la bibliothèque avec le compilateur
Objective-C, et faire l'édition de lien avec ruby comme si c'était du
C (c'est du C!).
-----(MyObj.m)---------
@implementation MyObj
- myMethod:(int)a
{
return [self ragnagna:(a+1)];
}
@end
id MyObj_myMethod(id obj,int a){
return [obj myMethod:a];
}
------------------------
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape...
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape. ..
Non, seulement compiler le .m avec Objective-C, et on obtient un .o
que l'ont peut lier comme si ça avait été un source C.
Par contre ça peut être utile de séparer en deux entêtes l'interf ace
Objective-C de l'interface C:
------(MyObj.h)------------
@interface MyObj
- myMethod:(int)a;
@end
-----(MyObj_C.h)-----------
extern id MyObj_myMethod(id obj,int a);
---------------------------
comme ça on peut #include <MyObj_C.h> dans les sources C qui utilisent
MyObj. Mais je ne sais pas si tu auras besoin d'un tel entête pour
utiliser MyObj.o avec ruby.
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape. ..
Non, seulement compiler le .m avec Objective-C, et on obtient un .o
que l'ont peut lier comme si ça avait été un source C.
Par contre ça peut être utile de séparer en deux entêtes l'interf ace
Objective-C de l'interface C:
------(MyObj.h)------------
@interface MyObj
- myMethod:(int)a;
@end
-----(MyObj_C.h)-----------
extern id MyObj_myMethod(id obj,int a);
---------------------------
comme ça on peut #include <MyObj_C.h> dans les sources C qui utilisent
MyObj. Mais je ne sais pas si tu auras besoin d'un tel entête pour
utiliser MyObj.o avec ruby.
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape. ..
Non, seulement compiler le .m avec Objective-C, et on obtient un .o
que l'ont peut lier comme si ça avait été un source C.
Par contre ça peut être utile de séparer en deux entêtes l'interf ace
Objective-C de l'interface C:
------(MyObj.h)------------
@interface MyObj
- myMethod:(int)a;
@end
-----(MyObj_C.h)-----------
extern id MyObj_myMethod(id obj,int a);
---------------------------
comme ça on peut #include <MyObj_C.h> dans les sources C qui utilisent
MyObj. Mais je ne sais pas si tu auras besoin d'un tel entête pour
utiliser MyObj.o avec ruby.
On 14 août, 15:29, Pascal Bourguignon wrote:Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape...
Non, seulement compiler le .m avec Objective-C, et on obtient un .o
que l'ont peut lier comme si ça avait été un source C.
Par contre ça peut être utile de séparer en deux entêtes l'interface
Objective-C de l'interface C:
------(MyObj.h)------------
@interface MyObj
- myMethod:(int)a;
@end
-----(MyObj_C.h)-----------
extern id MyObj_myMethod(id obj,int a);
---------------------------
comme ça on peut #include <MyObj_C.h> dans les sources C qui utilisent
MyObj. Mais je ne sais pas si tu auras besoin d'un tel entête pour
utiliser MyObj.o avec ruby.
oui, oui, j'ai écrit un tel header. MAIS j'ai un pb à la compil côté C/
Ruby...
alors, je m'explique.
compil ObjC :
echo `gcc -W -Wall -Wextra -I /System/Library/Frameworks/
Foundation.framework/Headers -framework Foundation -ObjC -o MyObj.o
MyObj.m main.m`
=> obligé d'ajouter un main.m ???
compil C extension to Ruby :
mon extconf.rb :
$CFLAGS << " -I /System/Library/Frameworks/Foundation.framework/
Headers "
$LDFLAGS << " -framework Foundation "
extension_name = 'myrobjc'
dir_config(extension_name)
create_makefile(extension_name)
au make :
~/work/C/RObjCC/ext%> make
cc -dynamic -bundle -undefined suppress -flat_namespace -L/opt/local/
lib -framework Foundation -L"/opt/local/lib" -o myrobjc.bundle
MyRObjC.o main.o MyObj.o -lruby -lpthread -ldl -lobjc
/usr/bin/ld: MyObj.o is input for the dynamic link editor, is not
relocatable by the static link editor again
peut-être devrais essayer de "bidouiller à la main" le Makefile ???
On 14 août, 15:29, Pascal Bourguignon <p...@informatimago.com> wrote:
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape...
Non, seulement compiler le .m avec Objective-C, et on obtient un .o
que l'ont peut lier comme si ça avait été un source C.
Par contre ça peut être utile de séparer en deux entêtes l'interface
Objective-C de l'interface C:
------(MyObj.h)------------
@interface MyObj
- myMethod:(int)a;
@end
-----(MyObj_C.h)-----------
extern id MyObj_myMethod(id obj,int a);
---------------------------
comme ça on peut #include <MyObj_C.h> dans les sources C qui utilisent
MyObj. Mais je ne sais pas si tu auras besoin d'un tel entête pour
utiliser MyObj.o avec ruby.
oui, oui, j'ai écrit un tel header. MAIS j'ai un pb à la compil côté C/
Ruby...
alors, je m'explique.
compil ObjC :
echo `gcc -W -Wall -Wextra -I /System/Library/Frameworks/
Foundation.framework/Headers -framework Foundation -ObjC -o MyObj.o
MyObj.m main.m`
=> obligé d'ajouter un main.m ???
compil C extension to Ruby :
mon extconf.rb :
$CFLAGS << " -I /System/Library/Frameworks/Foundation.framework/
Headers "
$LDFLAGS << " -framework Foundation "
extension_name = 'myrobjc'
dir_config(extension_name)
create_makefile(extension_name)
au make :
~/work/C/RObjCC/ext%> make
cc -dynamic -bundle -undefined suppress -flat_namespace -L/opt/local/
lib -framework Foundation -L"/opt/local/lib" -o myrobjc.bundle
MyRObjC.o main.o MyObj.o -lruby -lpthread -ldl -lobjc
/usr/bin/ld: MyObj.o is input for the dynamic link editor, is not
relocatable by the static link editor again
peut-être devrais essayer de "bidouiller à la main" le Makefile ???
On 14 août, 15:29, Pascal Bourguignon wrote:Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape...
Non, seulement compiler le .m avec Objective-C, et on obtient un .o
que l'ont peut lier comme si ça avait été un source C.
Par contre ça peut être utile de séparer en deux entêtes l'interface
Objective-C de l'interface C:
------(MyObj.h)------------
@interface MyObj
- myMethod:(int)a;
@end
-----(MyObj_C.h)-----------
extern id MyObj_myMethod(id obj,int a);
---------------------------
comme ça on peut #include <MyObj_C.h> dans les sources C qui utilisent
MyObj. Mais je ne sais pas si tu auras besoin d'un tel entête pour
utiliser MyObj.o avec ruby.
oui, oui, j'ai écrit un tel header. MAIS j'ai un pb à la compil côté C/
Ruby...
alors, je m'explique.
compil ObjC :
echo `gcc -W -Wall -Wextra -I /System/Library/Frameworks/
Foundation.framework/Headers -framework Foundation -ObjC -o MyObj.o
MyObj.m main.m`
=> obligé d'ajouter un main.m ???
compil C extension to Ruby :
mon extconf.rb :
$CFLAGS << " -I /System/Library/Frameworks/Foundation.framework/
Headers "
$LDFLAGS << " -framework Foundation "
extension_name = 'myrobjc'
dir_config(extension_name)
create_makefile(extension_name)
au make :
~/work/C/RObjCC/ext%> make
cc -dynamic -bundle -undefined suppress -flat_namespace -L/opt/local/
lib -framework Foundation -L"/opt/local/lib" -o myrobjc.bundle
MyRObjC.o main.o MyObj.o -lruby -lpthread -ldl -lobjc
/usr/bin/ld: MyObj.o is input for the dynamic link editor, is not
relocatable by the static link editor again
peut-être devrais essayer de "bidouiller à la main" le Makefile ???
En effet, MyObj.o est un exécutable au lieu d'être un module objet.
Utilise:
file MyObj.o
pour voir la différence.peut-être devrais essayer de "bidouiller à la main" le Makefile ???
Le reste me semble correct.
En effet, MyObj.o est un exécutable au lieu d'être un module objet.
Utilise:
file MyObj.o
pour voir la différence.
peut-être devrais essayer de "bidouiller à la main" le Makefile ???
Le reste me semble correct.
En effet, MyObj.o est un exécutable au lieu d'être un module objet.
Utilise:
file MyObj.o
pour voir la différence.peut-être devrais essayer de "bidouiller à la main" le Makefile ???
Le reste me semble correct.
unbewust writes:On 8 août, 22:22, Pascal Bourguignon wrote:Contrairement à C++, les fonctions en Objective-C sont des fonctions C
normales. Donc il faut compiler la bibliothèque avec le compilateur
Objective-C, et faire l'édition de lien avec ruby comme si c'était du
C (c'est du C!).
-----(MyObj.m)---------
@implementation MyObj
- myMethod:(int)a
{
return [self ragnagna:(a+1)];
}
@end
id MyObj_myMethod(id obj,int a){
return [obj myMethod:a];
}
------------------------
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape. ..
Non, seulement compiler le .m avec Objective-C, et on obtient un .o
que l'ont peut lier comme si ça avait été un source C.
Par contre ça peut être utile de séparer en deux entêtes l'interf ace
Objective-C de l'interface C:
------(MyObj.h)------------
@interface MyObj
- myMethod:(int)a;
@end
-----(MyObj_C.h)-----------
extern id MyObj_myMethod(id obj,int a);
---------------------------
comme ça on peut #include <MyObj_C.h> dans les sources C qui utilisent
MyObj. Mais je ne sais pas si tu auras besoin d'un tel entête pour
utiliser MyObj.o avec ruby.
unbewust <yvon.thora...@gmail.com> writes:
On 8 août, 22:22, Pascal Bourguignon <p...@informatimago.com> wrote:
Contrairement à C++, les fonctions en Objective-C sont des fonctions C
normales. Donc il faut compiler la bibliothèque avec le compilateur
Objective-C, et faire l'édition de lien avec ruby comme si c'était du
C (c'est du C!).
-----(MyObj.m)---------
@implementation MyObj
- myMethod:(int)a
{
return [self ragnagna:(a+1)];
}
@end
id MyObj_myMethod(id obj,int a){
return [obj myMethod:a];
}
------------------------
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape. ..
Non, seulement compiler le .m avec Objective-C, et on obtient un .o
que l'ont peut lier comme si ça avait été un source C.
Par contre ça peut être utile de séparer en deux entêtes l'interf ace
Objective-C de l'interface C:
------(MyObj.h)------------
@interface MyObj
- myMethod:(int)a;
@end
-----(MyObj_C.h)-----------
extern id MyObj_myMethod(id obj,int a);
---------------------------
comme ça on peut #include <MyObj_C.h> dans les sources C qui utilisent
MyObj. Mais je ne sais pas si tu auras besoin d'un tel entête pour
utiliser MyObj.o avec ruby.
unbewust writes:On 8 août, 22:22, Pascal Bourguignon wrote:Contrairement à C++, les fonctions en Objective-C sont des fonctions C
normales. Donc il faut compiler la bibliothèque avec le compilateur
Objective-C, et faire l'édition de lien avec ruby comme si c'était du
C (c'est du C!).
-----(MyObj.m)---------
@implementation MyObj
- myMethod:(int)a
{
return [self ragnagna:(a+1)];
}
@end
id MyObj_myMethod(id obj,int a){
return [obj myMethod:a];
}
------------------------
Compiler avec gcc -objc, dans une bibliothèque ou .o comme ruby le
veux, et dans ruby, appeler la fonction C MyObj_myMethod.
OK merci beaucoup pour l'info, je dois donc faire une compil en "deux
passes" la première pour l'ObjC et la seconde, normale pour le C en
omettant pas d'ajouter le/les *.o obtenu(s) dans la première étape. ..
Non, seulement compiler le .m avec Objective-C, et on obtient un .o
que l'ont peut lier comme si ça avait été un source C.
Par contre ça peut être utile de séparer en deux entêtes l'interf ace
Objective-C de l'interface C:
------(MyObj.h)------------
@interface MyObj
- myMethod:(int)a;
@end
-----(MyObj_C.h)-----------
extern id MyObj_myMethod(id obj,int a);
---------------------------
comme ça on peut #include <MyObj_C.h> dans les sources C qui utilisent
MyObj. Mais je ne sais pas si tu auras besoin d'un tel entête pour
utiliser MyObj.o avec ruby.
[...]
par contre j'ai un bus error au run :
[...]
Testing "RObjCC"
+----------------+
version() = MyRObjC version 0.0.1
cinData = 1
./sample.rb:55: [BUG] Bus Error
ruby 1.8.6 (2007-03-13) [powerpc-darwin8.9.0]
VALUE m_ragnagna ( VALUE self, VALUE inData)
{
int cinData = FIX2INT ( inData );
printf ( "cinData = %dn", cinData );
int coutData = MyObj_myMethod ( cinData ); // <-- bloque là...
[...]
par contre j'ai un bus error au run :
[...]
Testing "RObjCC"
+----------------+
version() = MyRObjC version 0.0.1
cinData = 1
./sample.rb:55: [BUG] Bus Error
ruby 1.8.6 (2007-03-13) [powerpc-darwin8.9.0]
VALUE m_ragnagna ( VALUE self, VALUE inData)
{
int cinData = FIX2INT ( inData );
printf ( "cinData = %dn", cinData );
int coutData = MyObj_myMethod ( cinData ); // <-- bloque là...
[...]
par contre j'ai un bus error au run :
[...]
Testing "RObjCC"
+----------------+
version() = MyRObjC version 0.0.1
cinData = 1
./sample.rb:55: [BUG] Bus Error
ruby 1.8.6 (2007-03-13) [powerpc-darwin8.9.0]
VALUE m_ragnagna ( VALUE self, VALUE inData)
{
int cinData = FIX2INT ( inData );
printf ( "cinData = %dn", cinData );
int coutData = MyObj_myMethod ( cinData ); // <-- bloque là...
QUELQUES Progrès :
int coutData = MyObj_myMethod ( NULL, cinData );
QUELQUES Progrès :
int coutData = MyObj_myMethod ( NULL, cinData );
QUELQUES Progrès :
int coutData = MyObj_myMethod ( NULL, cinData );
unbewust writes:QUELQUES Progrès :
int coutData = MyObj_myMethod ( NULL, cinData );
En effet c'est un peu mieux, mais envoyer des messages à nil ne va pas
faire grand chose...
À un moment ou à un autre, il faudra faire:
myObj=[[MyObj alloc]init];
et passer myObj à MyObj_myMethod...
unbewust <yvon.thora...@gmail.com> writes:
QUELQUES Progrès :
int coutData = MyObj_myMethod ( NULL, cinData );
En effet c'est un peu mieux, mais envoyer des messages à nil ne va pas
faire grand chose...
À un moment ou à un autre, il faudra faire:
myObj=[[MyObj alloc]init];
et passer myObj à MyObj_myMethod...
unbewust writes:QUELQUES Progrès :
int coutData = MyObj_myMethod ( NULL, cinData );
En effet c'est un peu mieux, mais envoyer des messages à nil ne va pas
faire grand chose...
À un moment ou à un autre, il faudra faire:
myObj=[[MyObj alloc]init];
et passer myObj à MyObj_myMethod...