Charlie,
I added Sittler's getopt program to my source tree and it works in fine, so we can go ahead and add it to the nco source tree and conditionally compile it when GNU's getopt_long is not present, therefore, everyone should have access to long arguments. (TODO 242) My question is: where should we put these 3rd party programs in the source tree? For long arguments, we need one c program and two additional header files (getopt.h being one). We'll use the existing autotools test to decide whether to compile these programs or not.
rorik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for doing this. Where to put the new files...
The options are to create a new directory for 3rd party
source code, or to keep everything in one directory.
I'm in favor of keeping everything in one directory if possible.
It may not be possible for files that are only to be
conditionally compiled/#included.
If we put Sittler's getopt in nco/src/nco, will the programs
_always_ use Sittler's getopt, even when the system has GNU getopt?
Using GNU getopt_long() when possible is preferable, as there are some
GNU features (I can't remember which) that Sittler does not include.
So if Sittler's getopt routines must reside in a separate directory in
order to be conditionally compiled, then we should agree on the name of
the new directory. I suggest nco/src/getopt.
In any case, please rename the Sittler files my_getopt.h, my_getopt.c
to nco_getopt.c, nco_getopt.h. Add these, and getopt.h, to nco/src/nco
if possible, and to nco/src/getopt if not. Of course, all three files
should be placed in the same directory.
I'm trying to think how the main() routines will conditionally access
Sittler's getopt. I come up with something like this:
#ifdef HAVE_GETOPT_H
#include <getopt.h> /* getopt_long() */
#endif /* !HAVE_GETOPT_H */
#ifdef NEED_GETOPT_LONG
#include "getopt.h" /* GNU getopt() functionality from BSD my_getopt() */
(or)
#include "../getopt/getopt.h" /* GNU getopt() functionality from BSD my_getopt() */
#endif /* !NEED_GETOPT_LONG */
Is that what you are doing? Or something different?
If you have the patience, could you try to incorporate the Sittler
stuff into bld/Makefile as well?
Thanks!
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Charlie,
The way I'd implement it is to check for getopt_long(), and if it does not exist, I have 'configure' add nco_getopt.c to the list of files included in libnco.a. This way, I remove the #ifdef HAVE_GETOPT_LONG from all the programs because everyone will get getopt_long(), it is just a matter of whether it comes from glibc or nco_getopt.c. If you have getopt_long(), nco_getopt.c is not compiled into libnco.a.
I have this working so long options are available on my Solaris 2.6 machine without glibc. However, I'll need to fix bld/Makefile otherwise things will start crashing because the #ifdef HAVE_GETOPT_LONG things are gone. To do this, I need to know which architectures to assume have glibc since we can't simply test for getopt_long() like autotools does. Do you agree that we can assume LINUX will always have glibc and no one else will?
If we can't come up with some assumptions for bld/Makefile, I guess we'll just scrap it and only let Linux users have long options until fully converting to autotools.
rorik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree your method is better because it removes
preprocessor tokens and is thus simpler. It is fine
to come up with assumptions for bld/Makefile---
in fact, that's exactly what I've done in the past.
I believe we can modify the libnco.a target in
bld/Makefile. If PVM_ARCH is one of a specified
list of architectures that NEED_GETOPT_LONG
then we insert nco_getopt.o into the library list.
Otherwise we leave it as is. Do you think you
can work this out?
The other way is to default to compiling nco_getopt.o
in the library. Architectures that HAVE_GETOPT_LONG then use the
GNU make filter-out command to remove nco_getopt.o from the liblist. Perhaps this is easier.
Both these solutions allow us to remove GETOPT_LONG tokens from the source code
which is what matters. But bld/Makefile must become
a little more complex as a result.
>Do you agree that we can assume LINUX will >always have glibc and no one else will?
Begin with the current assumption in bld/Makefile,
that is that a platform whose PVM_ARCH is
included in this string
LINUXALPHAFREEBSDWIN32
is using glibc and thus has getopt_long.
We'll make further exceptions as they arise.
Thanks,
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I committed some changes which should allow long options for non-glibc users. It works on my Solaris 2.6 machine. Give it a try on other non-glibc machines and see if it works (and hopefully doesn't break). I changed bld/Makefile as well, so either build method should work.
rorik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Charlie,
I added Sittler's getopt program to my source tree and it works in fine, so we can go ahead and add it to the nco source tree and conditionally compile it when GNU's getopt_long is not present, therefore, everyone should have access to long arguments. (TODO 242) My question is: where should we put these 3rd party programs in the source tree? For long arguments, we need one c program and two additional header files (getopt.h being one). We'll use the existing autotools test to decide whether to compile these programs or not.
rorik
Hi Rorik,
Thanks for doing this. Where to put the new files...
The options are to create a new directory for 3rd party
source code, or to keep everything in one directory.
I'm in favor of keeping everything in one directory if possible.
It may not be possible for files that are only to be
conditionally compiled/#included.
If we put Sittler's getopt in nco/src/nco, will the programs
_always_ use Sittler's getopt, even when the system has GNU getopt?
Using GNU getopt_long() when possible is preferable, as there are some
GNU features (I can't remember which) that Sittler does not include.
So if Sittler's getopt routines must reside in a separate directory in
order to be conditionally compiled, then we should agree on the name of
the new directory. I suggest nco/src/getopt.
In any case, please rename the Sittler files my_getopt.h, my_getopt.c
to nco_getopt.c, nco_getopt.h. Add these, and getopt.h, to nco/src/nco
if possible, and to nco/src/getopt if not. Of course, all three files
should be placed in the same directory.
I'm trying to think how the main() routines will conditionally access
Sittler's getopt. I come up with something like this:
#ifdef HAVE_GETOPT_H
#include <getopt.h> /* getopt_long() */
#endif /* !HAVE_GETOPT_H */
#ifdef NEED_GETOPT_LONG
#include "getopt.h" /* GNU getopt() functionality from BSD my_getopt() */
(or)
#include "../getopt/getopt.h" /* GNU getopt() functionality from BSD my_getopt() */
#endif /* !NEED_GETOPT_LONG */
Is that what you are doing? Or something different?
If you have the patience, could you try to incorporate the Sittler
stuff into bld/Makefile as well?
Thanks!
Charlie
Charlie,
The way I'd implement it is to check for getopt_long(), and if it does not exist, I have 'configure' add nco_getopt.c to the list of files included in libnco.a. This way, I remove the #ifdef HAVE_GETOPT_LONG from all the programs because everyone will get getopt_long(), it is just a matter of whether it comes from glibc or nco_getopt.c. If you have getopt_long(), nco_getopt.c is not compiled into libnco.a.
I have this working so long options are available on my Solaris 2.6 machine without glibc. However, I'll need to fix bld/Makefile otherwise things will start crashing because the #ifdef HAVE_GETOPT_LONG things are gone. To do this, I need to know which architectures to assume have glibc since we can't simply test for getopt_long() like autotools does. Do you agree that we can assume LINUX will always have glibc and no one else will?
If we can't come up with some assumptions for bld/Makefile, I guess we'll just scrap it and only let Linux users have long options until fully converting to autotools.
rorik
Hi Rorik,
I agree your method is better because it removes
preprocessor tokens and is thus simpler. It is fine
to come up with assumptions for bld/Makefile---
in fact, that's exactly what I've done in the past.
I believe we can modify the libnco.a target in
bld/Makefile. If PVM_ARCH is one of a specified
list of architectures that NEED_GETOPT_LONG
then we insert nco_getopt.o into the library list.
Otherwise we leave it as is. Do you think you
can work this out?
The other way is to default to compiling nco_getopt.o
in the library. Architectures that HAVE_GETOPT_LONG then use the
GNU make filter-out command to remove nco_getopt.o from the liblist. Perhaps this is easier.
Both these solutions allow us to remove GETOPT_LONG tokens from the source code
which is what matters. But bld/Makefile must become
a little more complex as a result.
>Do you agree that we can assume LINUX will >always have glibc and no one else will?
Begin with the current assumption in bld/Makefile,
that is that a platform whose PVM_ARCH is
included in this string
LINUXALPHAFREEBSDWIN32
is using glibc and thus has getopt_long.
We'll make further exceptions as they arise.
Thanks,
Charlie
I committed some changes which should allow long options for non-glibc users. It works on my Solaris 2.6 machine. Give it a try on other non-glibc machines and see if it works (and hopefully doesn't break). I changed bld/Makefile as well, so either build method should work.
rorik
Hi Rorik,
Good job. Seems to work fine with bld/Makefile on
my Linux, SGI, and IBM builds and the SGI and IBM
do not use glibc. I'm removing TODO 242.
Thanks!
Charlie