Re: Fortran95 binding for posix/gnulib

On 3-Jul-2011, Bruno Haible wrote: | subdirectory modules/fortran/ -, and that you follow the GNU conventions for | Fortran code (whatever these may be - you can find out by looking at octave | in octave-3.4.2/libcruft/ [3]). I wouldn't recommend trying to follow the style of the Fortran code in

Re: new module timer-time

On 07/20/11 02:01, Pádraig Brady wrote: > Well I suppose you could emulate a subset of timer_settime with setitimer, > but it would be awkward and I don't need that functionality at present. I might look into this issue at some point, for Emacs (which uses 'setitimer' and which can't reasonably fa

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

* Eli Zaretskii wrote on Wed, Jul 20, 2011 at 07:51:08PM CEST: > > Date: Wed, 20 Jul 2011 10:23:32 -0700 > > From: Paul Eggert > > CC: Ralf Wildenhues , 9...@debbugs.gnu.org, > > bug-gnulib@gnu.org > > > > On 07/20/11 01:48, Eli Zaretskii wrote: > > >> You need a separate stamp file to avoid th

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

On 07/20/11 01:48, Eli Zaretskii wrote: >> You need a separate stamp file to avoid this. > Or use move-if-change with config.status. That might be better, but it'd need a separate timestamp file, no? Otherwise, config.status would appear out-of-date to the top-level rule that runs 'configure', and

RE : Re: Fortran95 binding for posix/gnulib

On 20-Jul-2011, Bastien ROUCARIES wrote: | I agree libcraft is really ugly. | | Could you review the binding ? I don't use Fortran much these days. I don't write anything new using it, so I'm probably not the right person to review it. | Do you have use in octave? Not really. The Fortran cod

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

> Date: Wed, 20 Jul 2011 10:23:32 -0700 > From: Paul Eggert > CC: Ralf Wildenhues , 9...@debbugs.gnu.org, > bug-gnulib@gnu.org > > On 07/20/11 01:48, Eli Zaretskii wrote: > >> You need a separate stamp file to avoid this. > > Or use move-if-change with config.status. > > That might be better,

Re: HAVE_RELIABLE_FIONREAD & ioctl

Hi Sam, > I pulled ioctl module from gnulib because of a compilation error about > "ioctl_used_without_requesting_gnulib_ioctl" and I am wondering whether > the HAVE_RELIABLE_FIONREAD et al are still relevant. The problem that clisp/src/m4/ioctl.m4 tests against is fixed in Solaris 7 and newer, b

Re: close depends on fclose?!

Hi Sam, > Why does close depend on fclose?! The justification was in . > It seems that, close being a system call and fclose being a C library > function, the dependency should be the other way around: fclose should > depend on

HAVE_RELIABLE_FIONREAD & ioctl

Hi Bruno, I pulled ioctl module from gnulib because of a compilation error about "ioctl_used_without_requesting_gnulib_ioctl" and I am wondering whether the HAVE_RELIABLE_FIONREAD et al are still relevant. Also, I get this error on linux: /home/sds/src/clisp/sf/clisp/build-g-gxx/gllib/sys/ioctl.h:

RE : Re: Fortran95 binding for posix/gnulib

I agree libcraft is really ugly. Could you review the binding ? Do you have use in octave? Bastien Le 20 juil. 2011 18:44, "John W. Eaton" a écrit : On 3-Jul-2011, Bruno Haible wrote: | subdirectory modules/fortran/ -, and that you follow the GNU ... I wouldn't recommend trying to follow the

close depends on fclose?!

Hi Why does close depend on fclose?! It seems that, close being a system call and fclose being a C library function, the dependency should be the other way around: fclose should depend on close, but _NOT_ vice versa. E.g., CLISP uses close but never FILE or fclose et al, so, when pulling close, whi

Re: bug#9076: coreutils-8.12 uses SA_RESETHAND and SA_RESTART unconditionally

On 16/07/11 01:51, Paul Eggert wrote: > On 07/15/11 03:28, Pádraig Brady wrote: >> What I was getting was that it's probably better to leave >> the following to the app too: >> >> #ifndef SA_RESETHAND >> # define SA_RESETHAND 0 >> /* Now the app writer knows they need to handle this case */ >> #end

Re: new module timer-time

On 20/07/11 02:30, Bruno Haible wrote: > Pádraig Brady wrote: >> [timer-time.diff attachment] > >> +Check for timer_settime. Within HAVE_TIMER_SETTIME one can >> +assume timer_create is available too, as that is a >> +prerequisite to use timer_settime. > > And timer_gettime as well. I've verifie

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

> Cc: egg...@cs.ucla.edu, 9...@debbugs.gnu.org, bug-gnulib@gnu.org > Date: Wed, 20 Jul 2011 08:46:23 +0200 > From: "Ralf Wildenhues" > > I think you are. Once config.status is updated, the .h files' rules > are triggered, but since move-if-change never updates identical outputs > they will be tr