Testing platform

[Dr. David Kirkby]

I've got this bit of code, which checks for 'bash'. The user does not
need to use the bash shell, but many scripts assume the back shell and
will fail otherwise (no, I did not write them myself!)

Feel free to tell me how to criticise/improve this if you can.

AC_CHECK_PROG(foobar,bash,[yes],[no],[])
if test x$foobar  != xyes
then
     AC_MSG_WARN([Sorry, the 'bash' shell is needed to build
AC_PACKAGE_NAME])
     AC_MSG_WARN([All modern systems will have the 'bash' shell
installed somewhere])
     AC_MSG_WARN([On HP-UX you may try adding /opt/OpenSource/bin/ to
your path])
     AC_MSG_WARN([On AIX you may try adding /opt/pware/bin to your path])
     AC_MSG_ERROR([Exiting, as 'bash' was not found])
fi


As you can see, it offers suggestions of locations where 'bash' may be
found. Clearly, if the person is running on AIX, there is not much point
in telling them where to find bash on HP-UX.

Realistically, any attempt to cross-compile this program will fail. (In
fact, it would require a *major* effort to port it to AIX or HP-UX, but
I thought I'd add the locations of the bash binary on a couple of
systems I have access to).

Dave


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Dr. David Kirkby]

Dr. David Kirkby wrote:
> I've got this bit of code, which checks for 'bash'. The user does not
> need to use the bash shell, but many scripts assume the back shell and
> will fail otherwise (no, I did not write them myself!)

What I mean is, many scripts will assume the bash shell is somewhere in
the path.

Dave


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

Hello David,

* Dr. David Kirkby wrote on Thu, Oct 15, 2009 at 11:53:01PM CEST:
> I've got this bit of code, which checks for 'bash'. The user does
> not need to use the bash shell, but many scripts assume the back
> shell and will fail otherwise (no, I did not write them myself!)

The first question that comes up is: what is $foobar used for?
If it is needed for executing the configure script itself, then
this is the wrong approach, and Autoconf should let you integrate
your requirements in its better-shell search (which is currently
possible only using the undocumented _AS_DETECT_REQUIRED macro).

If you need it while building the package, i.e., on the $build system,
then an automatic search seems ok.  I'd however use AC_PATH_PROG, and
use its fourth argument to append, say, /opt/OpenSource/bin and
/opt/pware/bin and maybe /opt/freeware/bin or so to the path for
searching.

If you need $foobar on the $host system (i.e., after 'make install'),
then an automatic search only makes sense if you are not building for
another system, be that because you're cross-compiling, or just because
the other system has bash in a different directory.

In any case, you should not use $foobar for both; if you need both, have
two variables, which can default to the same thing.  And let your user
know which is what, and how they can be overridden.

> AC_CHECK_PROG(foobar,bash,[yes],[no],[])
> if test x$foobar  != xyes

The foobar variable will not be set to "yes" if bash is found anywhere,
but to the command you can use to invoke bash.

> As you can see, it offers suggestions of locations where 'bash' may
> be found. Clearly, if the person is running on AIX, there is not
> much point in telling them where to find bash on HP-UX.

I don't think that is much of a problem.  Of course, you could be
smarter, and run either of AC_CANONICAL_{BUILD,HOST} before and refine
your suggestions based on $build or $host; but that's like icing the
cake.

Hope that helps.

Cheers,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Dr. David Kirkby]

Ralf Wildenhues wrote:

> Hello David,
>
> * Dr. David Kirkby wrote on Thu, Oct 15, 2009 at 11:53:01PM CEST:
>> I've got this bit of code, which checks for 'bash'. The user does
>> not need to use the bash shell, but many scripts assume the back
>> shell and will fail otherwise (no, I did not write them myself!)
>
> The first question that comes up is: what is $foobar used for?
> If it is needed for executing the configure script itself, then
> this is the wrong approach, and Autoconf should let you integrate
> your requirements in its better-shell search (which is currently
> possible only using the undocumented _AS_DETECT_REQUIRED macro).

foobar was only intended to do the test to find if bash was in the path
or not. Other than in the lines I showed, it is not needed.

In fact, this whole configure script does need to produce a working
makefile (such a file is never used). The idea of this script is to
check that the build environment are sane and has all the requirements
to build all parts of Sage (some 250 MB compressed). We want to avoid
someone starting to build Sage, spending several hours doing so, then
only to find their version of perl is too old to build a package that
requires a specific version. We would rather highlight any issues we can
think of as soon as possible. One issue would be them not having bash in
their path.

Other programs in Sage will have their own configure scripts to actually
build the code. The script I wrote checks things like

* CC and CXX do not contain a mix of GNU and non-GNU compilers
* Perl on the system is not too old.
* GCC version (if gcc is used) is not 4.0.0, as that version has known
bugs.
* If gcc and g++ are used as compilers, they are the same version.
* gcc and g++ if used are not too old.
* Warns if non-GNU compilers are used, as Sage has never been built
without a GNU compiler, though it is my aim to make it build with Sun
Studio.

So this script is only for checking the perquisite parts are present.

Any makefile produced is ignored. In fact, I should remove the line of
code which creates the makefile, if there is one there, which I think
there is.

>
> If you need it while building the package, i.e., on the $build system,
> then an automatic search seems ok.  I'd however use AC_PATH_PROG, and
> use its fourth argument to append, say, /opt/OpenSource/bin and
> /opt/pware/bin and maybe /opt/freeware/bin or so to the path for
> searching.

If bash is not in the users path, the build process will fail, due to
things totally outside the control of this configure script. So if bash
is not in the path, an error must be produced. I guess it would be
useful to tell them where to find bash on their system if its not in
their path, so perhaps doing a search for them would be useful. But even
if bash is found, but is not in their path, the script must exit with an
error.

> If you need $foobar on the $host system (i.e., after 'make install'),
> then an automatic search only makes sense if you are not building for
> another system, be that because you're cross-compiling, or just because
> the other system has bash in a different directory.

bash will almost certainly be needed after 'make install'. However, that
does not mean

However, we need to be practical about this. It would require a huge
effort to port  Sage to HP-UX or AIX due to numerous GNUism. I doubt
more than a couple of the 100+ packages in Sage have ever been tested on
AIX or HP-UX until I started to test some. I doubt we would ever
distribute AIX or HP-UX binaries, but would expect people to build this
on their own system from source.

> In any case, you should not use $foobar for both; if you need both, have
> two variables, which can default to the same thing.  And let your user
> know which is what, and how they can be overridden.
>
>> AC_CHECK_PROG(foobar,bash,[yes],[no],[])
>> if test x$foobar  != xyes
>
> The foobar variable will not be set to "yes" if bash is found anywhere,
> but to the command you can use to invoke bash.

Strange that, as it seemed to work. If I understand you correctly,
(which I guess I am not), you are implying the script will not work at all.

I just modified it, so instead of search for bash, it searched for
'fddfbash' which were just a few random letters I added in front of the
command I was really looking for. The script seemed to have the desired
effect, and reported it could not find 'fddfbash'

checking for bison... bison -y
checking for fddfbash... no
configure: WARNING: Sorry, the 'bash' shell is needed to build Sage
configure: WARNING: All modern systems will have the 'bash' shell
installed somewhere
configure: WARNING: On HP-UX you may try adding /opt/OpenSource/bin/ to
your path
configure: WARNING: On AIX you may try adding /opt/pware/bin to your path
configure: error: Exiting, as 'bash' was not found
  ERROR: You do not have all of the prerequisites needed
  to build Sage from source.  See the errors above.
make[1]: *** [installed/prereq-0.5] Error 1


>> As you can see, it offers suggestions of locations where 'bash' may
>> be found. Clearly, if the person is running on AIX, there is not
>> much point in telling them where to find bash on HP-UX.
>
> I don't think that is much of a problem.  Of course, you could be
> smarter, and run either of AC_CANONICAL_{BUILD,HOST} before and refine
> your suggestions based on $build or $host; but that's like icing the
> cake.

I already had one of AC_CANONICAL_BUILD or  AC_CANONICAL_BUILD, but now
have both. How can I use them? On my HP-UX box, I now see in config.log

uname -s = HP-UX
ac_cv_build=hppa2.0w-hp-hpux11.11
ac_cv_host=hppa2.0w-hp-hpux11.11
build='hppa2.0w-hp-hpux11.11'
build_os='hpux11.11'
host='hppa2.0w-hp-hpux11.11'
host_os='hpux11.11'

I do not want to test for each individual release of HP-UX before giving
a message. There must be hundreds of minor releases, and I've no idea
what they are.

On my Solaris box, I see:

build='sparc-sun-solaris2.10'
build_os='solaris2.10'
host='sparc-sun-solaris2.10'
host_os='solaris2.10'

Again something with just 'solaris' would be useful. But there is some
point in me having these, as I would like to do a test if the box is
solaris 7, 8, or 9, and say it is unsupported. (Needless to say older
version are not supported either. I assume one would give
host_os='solaris2.5' and host_os='solaris2.6' on ancient systems, but
anyone building Sage on such an old release would want their head tested.

Is there any way of just getting this as 'solaris' or just 'hpux' or
'hp-ux' or 'aix' ?. Whilst I can see the point of have the version, I do
not want to have to do a test for every version of AIX, just to decide
what warning to give. I want a warning for any version of AIX, and any
version of HP-UX, as both of them seem to have not have bash in the path
  which a user might not expect. I've not no idea on very old Solaris
systems, but all modern ones have it in /usr/bin. I do not have access
to any machine with old versions of Solaris on, and can't be bothered to
install it on a Sun just to find out where bash is, given we do not
intend supporting Solaris versions of less than 10.

> Hope that helps.

Yes and no. I'm still confused about the best way to do this.

> Cheers,
> Ralf
>



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Bob Friesenhahn]

It seems to me that you are spending a lot of time trying to automate
warnings production when it may be more fruitful to simply document
any known limitations and workarounds in your package documentation.
Bash can be easily installed after the fact on most OSs.  Building on
Solaris 2.6 and later is not like going to the moon since they are
perfectly usable but lack recent updates like <stdint.h>.  I have not
found AIX or HP-UX to be much challenge either even though HP-UX has
bugs.

If C++ is involved, then the C++ compiler brand and version can be a
much bigger factor than the OS which happens to be used.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Dr. David Kirkby]

Bob Friesenhahn wrote:

> It seems to me that you are spending a lot of time trying to automate
> warnings production when it may be more fruitful to simply document any
> known limitations and workarounds in your package documentation. Bash
> can be easily installed after the fact on most OSs.  Building on Solaris
> 2.6 and later is not like going to the moon since they are perfectly
> usable but lack recent updates like <stdint.h>.  I have not found AIX or
> HP-UX to be much challenge either even though HP-UX has bugs.
>
> If C++ is involved, then the C++ compiler brand and version can be a
> much bigger factor than the OS which happens to be used.
>
> Bob
> --
> Bob Friesenhahn
> bfriesen@..., http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>

I'm not denying you are right, which is why I'm not going to exit the script,
but only issue a warning.

Solaris 10 is supported, in that we test on that. Other versions are not, so it
is not unreasonable to issue a warning to say that it's unsupported and and that
it may work, but may not.

The compiler is a big issue. At the moment, about 75% of the code in Sage
reconises the CC and CXX variables, the other 75% ignore them completely, and
use gcc/g++. One bit will use the GNU C compiler for compiling C files, then
switches to using the Sun C compoiler for compiling C++ files. Hence the build
will fail if the Sun compiler is on the system (it does not even need to be in
the path).

There are many obstacles to getting this build with the Sun compiler on Solaris
- see:

http://sagetrac.org/sage_trac/ticket/7056

I just want to restrict by warning against the use of older Solaris releases.

On HP-UX there are more problems, though many of them are a result that certain
bits of code was written with Solaris in mind, but not HP-UX

http://sagetrac.org/sage_trac/ticket/7168


Dave


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* Dr. David Kirkby wrote on Fri, Oct 16, 2009 at 12:15:19PM CEST:

> Ralf Wildenhues wrote:
> >In any case, you should not use $foobar for both; if you need both, have
> >two variables, which can default to the same thing.  And let your user
> >know which is what, and how they can be overridden.
> >
> >>AC_CHECK_PROG(foobar,bash,[yes],[no],[])
> >>if test x$foobar  != xyes
> >
> >The foobar variable will not be set to "yes" if bash is found anywhere,
> >but to the command you can use to invoke bash.
>
> Strange that, as it seemed to work. If I understand you correctly,
> (which I guess I am not), you are implying the script will not work
> at all.

You are right.  I simply totally forgot to look past
  AC_CHECK_PROG(foobar,bash

> I already had one of AC_CANONICAL_BUILD or  AC_CANONICAL_BUILD, but
> now have both. How can I use them?

  case $host in
  *-*-solaris*) ... ;;
  *-*-hpux*) ... ;;
  esac

or
  case $host_os in
  solaris*) ... ;;
  hpux*) ... ;;
  esac

> I do not want to test for each individual release of HP-UX before
> giving a message. There must be hundreds of minor releases, and I've
> no idea what they are.

So just test for the inital part of the OS name as above.

HTH.

Cheers,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf