récupérer dans mon code des variables depuis le config.ac

salut tous...

comme vous le savez, les fonctions g_rename et g_mkdir n'existent pas sous windows, elles y sont sous unix...
le projet que j'ai, tourne sous unix, il m'est demandé de porter ce projet sur windows..

le projet est developpé en C++.
j'utilise dev cpp
comment je pourrai faire le test, que si le OS est unix d'utiliser les fonctions g_renam et g_mkdir , s'il s'agit de windows d'utiliser les fonctions rename et mkdir...

j'ai un fichier config.ac, est ce que c'est possible de définir un variable qui récupère l'OS (win32, ou unix ..), et dans mon code du projet je récupère ce variable??

merci d'avance pour tout réponse

Tu peux faire ça dans ton code :

Code:

---

1 2 3 4

#ifdef _WIN32 #define g_rename rename #define g_mkdir mkdir #endif

---

Normalement le compilateur définit divers macro qui t'aident à détecter le compilo / la plateforme. Par exemple:

Code:

---

1 2 3 4 5 6

#ifdef WIN32   // placer ici le code Windows   #endif

---

edit: arf, grillé :)
Je complète alors en disant qu'on en croise plusieurs, WIN32 et _WIN32 notamment. Faut tester sur ton compilo.

merci pour cette réponse...

mais je voudrais faire ce test dans le config.ac
quelqu'un a une idée ??

merci

A qui correspond ce fichier ?

le config.ac correspond à mon projet..

Mais concrètement, ça s'utilise avec quoi ? Y'a quoi dedans ?

voici le code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91

[code]dnl -------------------------------- dnl Initialization macros. dnl --------------------------------   AC_INIT(src/qptolemy,0.1) AM_INIT_AUTOMAKE AM_MAINTAINER_MODE AC_CONFIG_SRCDIR(config.h.in) AM_CONFIG_HEADER(config.h)   dnl ----------------------------------------------- dnl Package name and version number (user defined) dnl -----------------------------------------------     dnl -------------------------------- dnl Package name and version number dnl --------------------------------     dnl ----------------------------------------------- dnl Checks for programs. dnl -----------------------------------------------   AC_PROG_CC AC_PROG_CXX AC_PROG_CPP AC_DISABLE_STATIC AM_PROG_LIBTOOL AM_SANITY_CHECK AC_LANG_CPLUSPLUS AC_PROG_LN_S AC_PROG_MAKE_SET   dnl ***** checks for typedefs, structures, and compiler characteristics *******   AC_HEADER_STDBOOL AC_C_CONST AC_C_INLINE AC_TYPE_SIZE_T       dnl ***** check for library ***************************************************   PKG_CHECK_MODULES(QPTOLEMY, glibmm-2.4 >= 2.4.0) AC_SUBST(QPTOLEMY_LIBS) AC_SUBST(QPTOLEMY_CFLAGS)   PKG_CHECK_MODULES(GUI, gtkmm-2.4 >= 2.4.0 libglademm-2.4 >= 2.4.0) AC_SUBST(GUI_LIBS) AC_SUBST(GUI_CFLAGS)   PKG_CHECK_MODULES(XML, libxml++-2.6 >= 2.6.0) AC_SUBST(XML_LIBS) AC_SUBST(XML_CFLAGS)   #PKG_CHECK_MODULES(LEARNER,) #AC_SUBST(LEARNER_LIBS) #AC_SUBST(LEARNER_CFLAGS)       dnl ***** Check for debug *****************************************************   if test "$enable_debug" = yes ; then CXXFLAGS="-O0 -Wall -W -g -Werror" fi AC_SUBST(CXXFLAGS)     dnl ----------------------------------------------- dnl Generates Makefile's, configuration files and scripts dnl -----------------------------------------------   AC_CONFIG_FILES(Makefile src/Makefile src/model/Makefile src/model/parser/Makefile src/model/metric/Makefile src/learner/Makefile src/gui/Makefile src/utils/Makefile src/utils/jikes/Makefile src/utils/svg/Makefile src/utils/validator/Makefile qptolemy.pc)   AC_OUTPUT [/code]

---

alors, est ce que c'est possible de faire ca, ou pas??

merc i

Très joli le code de config.ac, mais... c'est quoi comme langage ? Ca s'utilise avec quel outil ? Ca sert à quoi ?

Les autotools, c'est bien mais ... pour du C sous *nix.
Tu vas avoir a) du mal à les utiliser pour du code win32, et c'est limite b) s'embéter pour pas grand chose en C++.

a) parce que qu'il te faudra un shell capable de lancer des compilos win32, et tout simplement l'ensemble configure & cie.

b) parce qu'il existe quantité de bibliothèques portables qui font abstraction, pour nous, des détails non portables. Il y a des chances que tu trouves ce que tu cherches dans boost. Ce qui lève tout intérêt aux autotools.