[parted-devel] A few queries.

David Cantrell dcantrell at redhat.com
Tue Mar 20 16:36:08 CET 2007


On Tue, 2007-03-20 at 14:00 +0530, Debarshi 'Rishi' Ray wrote:
> > commit c1b00586c9296e03d2445de20a3d44c1c949979e
> > Author: David Cantrell <dcantrell at redhat.com>
> > Date:   Mon Mar 19 14:01:46 2007 -0400
> >
> >   Conditionalize the System Z stuff correctly.  We get headers installed on non-System Z
> > platforms, but the code only compiles on that platform.
> 
> If 'uname -m' is a better option than checking for __s390__ (as
> suggested by the following patch), then why revert to using __s390__?

Because 'uname -m' ending up not working.  Or I didn't know how to make
it work in a Makefile.am file.

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

> > commit 5167881e1f44c1bd4ccf4ed15daeeaa7af75558d
> > Author: David Cantrell <dcantrell at redhat.com>
> > Date:   Mon Mar 19 11:20:55 2007 -0400
> >
> >    Remove the COMPILE_FOR_S390 flag-setting stuff.  It wasn't correct anyway.  Take a
> > kernel-style approach and check uname -m to see if we are on s390.  If so, we build for
> > zSeries.  Otherwise we do not.
> 
> I find that we have gone back to using #ifdef...#endif blocks to
> conditionally compile the DASD specific files. Why I say back is
> because this looks like a regression since the preferred way seems to
> be to use AM_CONDITIONAL. The rationale is stated in this "Best
> practices with autotools" article:
> http://programming.linux.com/article.pl?sid=05/08/11/1923248&tid=22 as
> follows:
> 
> "Many projects, to avoid compiling code for specific code paths, add
> the entire files in #ifdef ... #endif preprocessor conditionals. While
> this usually works, it makes the code ugly and error-prone, as a
> single statement out of the conditional block can be compiled where
> the source file is not needed. It also misleads users sometimes, as
> the source files seem to be compiled in situations where they don't
> make sense."
> 
> If 'uname -m' is a better way to do it than checking for the __s390__
> macro, then can't we have a 'uname -m' based test using Autotools
> itself?

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.  To me,
having these lines:

	#if (defined (__s390__) || defined (__s390x__))

in source files is easier to deal with than automake macros and stuff in
Makefile.am files.  My original plan was to replace the COMPILE_FOR_S390
tests with a 'uname -m' test in the Makefile.am files where the source
and headers were conditionalized out.  But automake complained at me
when I tried to add GNU make-specific directives to the Makefile.am
file.  Not having time to deal with automake, I went with the #if
method.

-- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Westford, MA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20070320/bc0dce1a/attachment.pgp


More information about the parted-devel mailing list