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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.