[parted-devel] A few queries.
Debarshi 'Rishi' Ray
debarshi.ray at gmail.com
Mon Mar 26 13:20:34 CET 2007
>> Is there any reason to install the headers on non-DASD systems also. I
>> recall that you were against installing them to preserve consistency.
>> Since the DASD specific code would not be compiled into the library,
>> would it not mislead the user if the headers are present? I am
>> curious. :-)
> They don't hurt anything. It's easier to take this path from my
> understanding.
Well it is not a matter of hurting. Is there any reason to provide the
header, when the corresponding code is not being compiled into the
library?
Why is it easier?
> I'm using the #ifdef method in 1.8.x because the AM_CONDITIONAL stuff
> simply was not working. If AM_CONDITIONAL is preferred, then I want to
> look at it more closely. What we had wasn't working at all.
That is not the fault of AM_CONDITIONAL. It was because that the test
I had written using AC_EGREP_CPP was wrong. Apparently the best way to
do it is using AC_COMPILE_IFELSE and AC_LANG_PROGRAM.
((http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoconf_15.html
last example on the page)
I have attached a patch. It should work on both S390 and non-s390
machines. Although it puts the DASD specific files in the tarballs,
they are only compiled and installed if __s390__ or __s390x__ are
defined.
Comments?
Happy hacking,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dasd.diff
Type: text/x-patch
Size: 3309 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20070326/c5e79ad0/dasd.bin
More information about the parted-devel
mailing list