Re: infinint-type dependent headers?
Denis Corbin <[email protected]>
| Newsgroups | gmane.comp.sysutils.backup.dar.general |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Denis Corbin wrote: | Johnathan Burchill wrote: | | [...] | | | On to the header installation issue: | | Denis Corbin wrote: | | | |>I think the best thing to do (in a long term view) is for me | |>to change the way included files are installed, for they do | |>not depend on any macro (I mean #define). The problem about substution of #define is that it requires a specific pre-processor. gcc, with -E option, does only invoke the pre-processor but it does #define substitution as well as #include substitutions, which is not what we want here (dar headers must not have copies of system headers in them). Doing my own pre-processor would require flex+bison dependencies and a lot of work compared to what it has to be used for. What I've found more simple, and I beleive still correct, is to rename the macro defined by autoconf (prefixing them with LIBDAR_). This way other software that rely on libdar (like kdar) can still use autoconf and not interact anymore with libdar header's "#define". This substitution takes place at the final stage of the dar package installation. Thus, dar package keep using autoconf, with all the normal #define generated by the "configure" script. | | | |>may need to have both installed libdar32 and libdar64, this | |>is possible for the library as the do not have the same | |>name, but the problem is that the included files share the | |>same name. So I suppose that making several subdirectories | |>like "include/dar/32" "include/dar/64" | |>"include/dar/infinint" is a possible solution, to have | |>several version of each included files. | | | | | | I do not see why this would be necessary. Doesn't your MODE switch | already | | take care of the various infinint types? I do not see how the headers | | differ that much that you need separate directories for them. | |[...] | | But, you are right, I could subsitute all macro except MODE, and keep | the same location for included files. This would not change the libdar | usage. So we keep a single set of headers under <prefix>/include/dar , and we use the MODE macro according to the libdar version kdar wants to link against (libdar32, libdar64 or libdar), as usually. But, "MODE" is not explicitly related to libdar, and for consistency with other #define, I will rename it also, under LIBDAR_MODE. The usage stays the same, but at least, this avoids potential conflicts with other softwares about this common macro name (autoconf seems to use a MODE macro... ). | Cheers, Denis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAHrBmpC5CI8gYGlIRAsbPAKC917mICfSN1eQfHqimCKHYA1L50wCgyrPm NSLfQUjATIwCwbCn/QrKCmk= =EL6k -----END PGP SIGNATURE----- ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn