Re: infinint-type dependent headers?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johnathan Burchill wrote:
| Hi Denis,

Hello Johnathan,

|
| I thought it was appropriate to move this topic over to dar-discussions.
| Excuse me if this is not okay.

no problem, you are right.

|
| As far as the infinint::... compilation problem when largefile support is
| enabled in libdar, I copied several lines from your configure.ac and put
| them in my autoconf file:
|[...]
|
| That fixed the kdar compile problem when largefile support is enabled.

yes, but if a user does not call both configure script (from dar and
kdar) the same way (for example one with largefile support and the other
without), the compilation problem will re-appear.

|
| 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). But, a given user
|
|
| Do you mean you would have the MODE=?? not defined anymore?
|

yes, it is what I meant: Instead of defining the MODE macro you would
use different include directives :

~   #include <libdar/32/libdar.hpp>
or
~   #include <libdar/infinint/libdar.hpp>

and link with the appropriate library (libdar32.a or libdar.a ...or
their dynamic counterparts).

|
|>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.

yes, the MODE macro takes care of that, the problem concerns all the
macro defined by autoconf which are shared by dar and kdar. Both piece
of software may have different settings for theses values, and as we saw
in this bug, as dar's headers do expect this macros to have the same
value as they had at libdar compilation time, any program that relies on
libdar is not free to use autoconf as it wants or needs.

So my idea was to substitue all macro defined by the configure script in
the header files at installation time. This way, installed header would
let software that rely on libdar (and their users) free to use autoconf
(and the generated configure script) as they want.

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.

|
|
|>this would imply a change in kdar to have and use  #include
|><dar/64/libdar.hpp>  or #include <dar/infinint/libdar.hpp>
|>and so on.
|>

right, in my original proposition.

|
| In which case I would have to
| #include <dar/MODE_DIR/libdar.hpp>
| where MODE_DIR is defined at configure time? i.e. MODE_DIR is one of
| 32, 64, or infinint?
|

yes something like that should be possible, at the difference here that
MODE_DIR is specific to kdar.

|
|>If you have better idea about the subdirectories name,
|>thanks to let me know. And also If you have another
|>solution. :-)
|>
|
| Looks like I need to study the problem some more.:) I'm pretty sure I'm
| missing the point altogether, so I'll get back to you about it later.
|

Yes, let's take enough time to go in the good direction. :-)

|
|>Denis.
|
|
| JB

Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFADkZJpC5CI8gYGlIRAgbgAKCI+y2uyyT4HXKBubIkdKAmCturHACcCmQB
VoRODqc4k3afFBn8csP3upI=
=cANr
-----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