Re: [bug-gnulib] New GNULIB glob module?

[Paul Eggert]

Derek Price <[EMAIL PROTECTED]> writes:

> After that I will write up a ChangeLog entry for the glob-glibc2gnulib
> diff and submit our changes back to the glibc team, unless someone here
> who is used to working with them would like to take a go at the actual
> submission part.  Perhaps it would be smoother if someone already known
> to the glibc team introduced me and this patch?

Yes, probably.  I'm willing to have a go at it.

I suggest submitting two patches.

(1) the part that makes it work with gnulib.
(2) the bug fix.

It's OK for (2) to assume that (1) has already been applied.

Each patch should have its own Changelog entry.

> Is the "definitive" version of shared files usually in glibc,
> gnulib, or wherever someone last remembered to merge when this
> happens?

It's supposed to be in glibc, but we're not as good at keeping glibc
up to date as we should be.


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: CVS update [cvs1-11-x-branch]: /ccvs/windows-NT/

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:

>Log:
> * run.c: Substitute "xrealloc" function for "xnrealloc" call from
> "run_add_arg_p" function.


There is an xnrealloc function in lib/xmalloc.c.  Isn't that being
compiled on Windows?

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCmSgyLD1OTBfyMaQRAgWmAJ4lGLn+3E3KJ1SUvE/uG3UwNOFqfQCgmcvV
5rwGa2ryMxFCJwlCKlkX1bM=
=7SI3
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: cvs client: refetching unpatchable files

[Larry Jones]

James Croxford writes:
> 
> This is a multi-part message in MIME format.

Please do not send MIME and/or HTML encrypted messages to the list.
Plain text only, PLEASE!

> The version of the CVS command we have is 1.11

That version is ancient -- the current stable release is 1.11.20!  I
strongly suggest upgrading both the client(s) and the server (although
the server is most important): .  That may well
fix the problem.

> I need to understand why a patch would fail, or at least some of the
> possible reasons, and ideally would like to fix this so the patch works if
> at all possible.

The usual reason is that something has changed the file without changing
the timestamp.

> *
>  Disclaimer

Such disclaimers on messages sent to public mailing lists are silly at
best.  Please give your lawyers a cookie and put them in a nice padded
room where they won't hurt themselves or annoy others.

-Larry Jones

The living dead don't NEED to solve word problems. -- Calvin


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32

[Derek Price]

Conrad T. Pino wrote:

>I propose we do both, I'll edit and test, you coach:
>  
>

Sure.

>I'm OK with leaving WINDOWS32 undefined in our project.  I'd like to see
>an improvement in the WINDOWS32 code for the benefit of other projects if
>for no other reason than saying thank you to GLib and GNULib by sending
>back some useful code.
>
>I will improve "pwd.c" also so long as cutting and pasting is acceptable
>between "pwd.c" and "glob.c" is acceptable.
>  
>

Hrm?  Cutting and pasting in which direction.  You can try and get the
pwd.c module into GNULIB it might work.  I just ran across the GNULIB
execute module which seems to have some Windows specific code.  The
macros stuff is already in GNULIB, so if you could abstract some of the
Windows specific stuff out into those macros, I think it can only simplify.

>The bit of work concerns me only if we have an open issue that breaks the
>Windows build.  If the Windows build works I'll work on this issue.
>  
>

I believe the Windows build was working last night and probably is again
after my recent commit..

>I assume "inadvertantly fix...former" is the "pwd.c" improvement.  If so
>I share your motivation and agree.
>  
>

Yes.

>>Do you really expect this to be set if %USERPROFILE% is not?  It depends
>>on it...
>>
>>
>
>Windows NT, 2000, XP and 2003 will set the values.  I expect trouble only when
>the user has used command window to undefine or redefine which is unlikely.
>  
>

I'm not sure why earlier CVS developers missed the %USERPROFILE% value
then, unless it was missing in earlier versions of NT, but if you say
so...  Anyhow, if we leave %HOMEDRIVE%%HOMEPATH% as a fallback value, it
shouldn't be a big deal to add hte new handling.

>No "ALLUSERSPROFILE" does not depend on "USERPROFILE" and you are correct on
>it's use as shorthand to illustrate they typically have a common root.
>  
>

Why even process ALLUSERSPROFILE here?  As long as %USERPROFILE% and
%HOMEDRIVE%%HOMEPATH% are susually set, then if they are unset then
something is wrong, I would think.  It just doesn't sound like a
reasonable fallback to me.  The UNIX fallback, or even "secure" method
is to read the /etc/passwd file.  Maybe the closest fallback on Windows
is to read the registry?

>Power users to modify the registry can relocate their profile away from the
>default profile root.
>
>Networked users with file server resident profiles is another case.
>  
>

True.  Is %USERPROFILES% the best we can do here?

>Windows has no support for "~" and similar.  We can provide it as a reference
>to "$HOME", "$USERPROFILE" and/or "$HOMEDRIVE", "$HOMEPATH" combination.
>  
>

As part of glob, and to support consistent usage in CVS config files,
supporting "~" still seems reasonable.  Determining what that means is
up to us.  CVS supported the non-standard $HOME on Windows 95/98/ME
because there was nothing standard.  It is possible that continuing to
support that for glob is fine sine it won't normally be set anyhow, but
what we should aim at is whatever seems morally closest in Windows.


>>>+  if (home_dir == NULL || home_dir[0] == '\0')
>>>+  {
>>>+  /*"$SystemDrive/users" is Windows NT 4 specific
>>>+
>>>+NEW INSTALLS of Windows 2000 and later use
>>>+"$SystemDrive/Documents and Settings"
>>>+
>>>+UPGRADES use previous location
>>>+
>>>+The default user profile can't be found with an 
>>>environment
>>>+variable.  It's location is in the Windows 
>>>registry.
>>>+
>>>+The SystemDrive environment variable is an 
>>>alternative.
>>>+*/
>>>+  home_dir = "c:/users/default"; /* poor default */
>>>+  }
>>>  
>>>
>>CVS already uses %HOMEDRIVE%%HOMPATH% on windows (set automatically for
>>a long time on NT and carried through to XP), which sounds like another
>>good possibility.  I think it might predate %USERPROFILE%, so
>>%USERPROFILE% should probably be checked first.  It might be nice to
>>roll this all together into one place, like the pwd.c stuff, to avoid
>>having different portions of hte program do different things on Windows
>>with respect to $HOME.  Then the get_homedir() function from
>>windows-NT/filesubr.c should just check %HOME% then make the getpwname
>>(getlogin()) call.
>>
>>
>
>I can't say which came first but it's not particularly relevant to me.
>  
>

Newest is probably best, from the standpoint of supporting what
Microsoft declares most current first.  Supporting the legacy stuff in
chronologically reverse order should manage to support both old systems
and those who unset their %USERPROFILE% to allow their old setup, which
knew how to deal with %HOMEDRIVE%%HOMEPATH%, or whatever, to work.

Is %USERPROFILE% and %HOMEDRIVE%%HOMEPATH% really the same thing?  Now
that you have me talking about it, old memories that say the
%USERPROFIL

Re: [bug-gnulib] New GNULIB glob module?

[Derek Price]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

>breaks the Windows build since Microsoft does NOT provide "sys/cdefs.h"
>implementation.


Yes.  Since we don't run configure on Windows, _SYS_CDEFS_H needed to be
defined to 1 in the windows-NT/config.h.in.in.  I've done so and
installed it.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCmPCxLD1OTBfyMaQRAqfrAKDcNY5MOH8PnOYdID9dZgqNxj8b6wCgy3E6
ELXlzCQfccQvTI7rfH3GpY0=
=EgB+
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

RE: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32

[Conrad T. Pino]

Hi Derek,

> From: Derek Price
> 
> Conrad T. Pino wrote:
> 
> >Yes, the Windows build completes.  Can you explain what "home_dir" value
> >will be in the "WINDOWS32" undefined logic?
> 
> It looks like it would call, basically, getpwnam (getlogin()).  There
> are substitutes for both in windows-NT/pwd.c, though it doesn't look
> like they are doing much useful.

I'd like to see a general improvement.

> >How about defining "WINDOWS32" and using the patch below?
> 
> Maybe this would be preferable.  This would enable some of the [a-z]:/
> swithcing other places in the file as well.  Of course, it's possible
> much of that could be abstracted out using the FILE_SYSTEM_PREFIX_LEN &
> ISSLASH macros.

I don't have a preference at the moment and I agree with macros comment.

> My feeling is that it might be nice to move as much of your patch as
> possible into pwd.c, abstract out as much of the drive letter prefix
> stuff as possible into the aformentioned macros, skip defining
> WINDOWS32, and see how things look, but it might be a bit of work.  If
> you'd rather take the easy way out, I won't argue, but the former might
> inadvertantly fix a few other hitherto unnoticed or ignored bugs on Windows.

I propose we do both, I'll edit and test, you coach:

I'm OK with leaving WINDOWS32 undefined in our project.  I'd like to see
an improvement in the WINDOWS32 code for the benefit of other projects if
for no other reason than saying thank you to GLib and GNULib by sending
back some useful code.

I will improve "pwd.c" also so long as cutting and pasting is acceptable
between "pwd.c" and "glob.c" is acceptable.

The bit of work concerns me only if we have an open issue that breaks the
Windows build.  If the Windows build works I'll work on this issue.

I assume "inadvertantly fix...former" is the "pwd.c" improvement.  If so
I share your motivation and agree.

> >The #if logic was cut from "lib/glob.c" lines 53 through 71 with the
> >extras discarded.  My patch is a quick hack.  I would appreciate it if
> >you choose to make improvements.
> 
> No, I think what you did is fine, at least until more than one #ifdef is
> needed.  The version in glob.c is nice for making the rest of the
> dirent/direct switching pretty transparent, but it's not needed yet.

Thank you.

> >Index: lib/glob.c
> >===
> >RCS file: /cvs/ccvs/lib/glob.c,v
> >retrieving revision 1.15
> >diff -u -p -r1.15 glob.c
> >--- lib/glob.c   25 May 2005 20:23:38 -  1.15
> >+++ lib/glob.c   26 May 2005 10:57:36 -
> >@@ -524,8 +525,45 @@ glob (const char *pattern, int flags,
> > home_dir = "SYS:";
> > # else
> > #  ifdef WINDOWS32
> >+  /* Windows doesn't set HOME, honor it if user sets it */
> >   if (home_dir == NULL || home_dir[0] == '\0')
> >-home_dir = "c:/users/default"; /* poor default */
> >+  {
> >+  /* Windows sets USERPROFILE like UNIX sets HOME */
> >+  home_dir = getenv( "USERPROFILE" );
> >+  }
> >+  if (home_dir == NULL || home_dir[0] == '\0')
> >+  {
> >+  /* Windows sets APPDATA to "$USERPROFILE/Application Data" */
> >+  home_dir = getenv( "APPDATA" );
> >+  }
> 
> Do you really expect this to be set if %USERPROFILE% is not?  It depends
> on it...

Windows NT, 2000, XP and 2003 will set the values.  I expect trouble only when
the user has used command window to undefine or redefine which is unlikely.

> >+  if (home_dir == NULL || home_dir[0] == '\0')
> >+  {
> >+  /* Windows sets ALLUSERSPROFILE to "$USERPROFILE/../All 
> >Users" */
> >+  home_dir = getenv( "ALLUSERSPROFILE" );
> >+  }
> 
> Does this really depend on %USERPROFILE% too or is this just your
> shorthand to refer to the user-profile directory?

No "ALLUSERSPROFILE" does not depend on "USERPROFILE" and you are correct on
it's use as shorthand to illustrate they typically have a common root.

Power users to modify the registry can relocate their profile away from the
default profile root.

Networked users with file server resident profiles is another case.

> >+  if (home_dir == NULL || home_dir[0] == '\0')
> >+  {
> >+  /* Windows sets SystemRoot to installation value typically
> >+ C:/WinNT but frequently C:/Windows */
> >+  /* This may be a bad idea but it's an alternative to the root 
> >*/
> >+  home_dir = getenv( "SystemRoot" );
> >+  }
> 
> I'm not sure how I feel about using SystemRoot as a fallback for ~ or
> ~username...  sounds unintuitive and possibly dangerous.

Windows has no support for "~" and similar.  We can provide it as a reference
to "$HOME", "$USERPROFILE" and/or "$HOMEDRIVE", "$HOMEPATH" combination.

> >+  if (home_dir == NULL || home_dir[0] == '\0')
> >+  {
> >+  /*"$SystemDrive/users" is Windows NT 4 specific
> >+
> >+NEW I

Feature Branch Windows Build Broken - #include fails

[Conrad T. Pino]

Hi Derek,

I'm not recommending this as a solution since it's not a general solution
but "mkdir windows-NT/sys; touch windows-NT/sys/cdefs.h" allows Windows
build to complete with no errors and no warnings.

Conrad

Configuration: libcvs - Win32 Debug
Compiling...
glob.c
Creating library...
Configuration: libdiff - Win32 Debug
Creating library...
Configuration: cvsnt - Win32 Debug
Linking...
LINK : LNK6004: .\WinDebug\cvs.exe not found or not built by the last 
incremental link; performing full link

cvs.exe - 0 error(s), 124 warning(s)


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

RE: [bug-gnulib] New GNULIB glob module?

[Conrad T. Pino]

Hi Derek,

> From: Derek Price
> 
> Done.  I added this comment to both glob_.h & glob.m4, with different
> comment leaders, of course:
> 
> /* Note the reversal of the common HAVE_SYS_CDEFS_H idiom below.  In this
>way, #ifndef _SYS_CDEFS_H may be used to include  both when
>it has been checked for via the GNULIB configure test and found and when
>it has not been checked for, which we can presume means that the 
>GNULIB shares with GLIBC is being included as a system header and not as
>part of GNULIB, in which case  may be assumed.  */
> 
> I'm going to commit what I have as the new glob module soon if noone
> says otherwise.  I and the CVS team made a few more minor changes to
> make it work on Solaris, BSD, and Windows, but it is now compiling and
> running on some 7 diverse platforms.
> 
> After that I will write up a ChangeLog entry for the glob-glibc2gnulib
> diff and submit our changes back to the glibc team, unless someone here
> who is used to working with them would like to take a go at the actual
> submission part.  Perhaps it would be smoother if someone already known
> to the glibc team introduced me and this patch?  Is the "definitive"
> version of shared files usually in glibc, gnulib, or wherever someone
> last remembered to merge when this happens?

The recent commit:

User: dprice  
Date: 05/05/28 10:39:04

Modified:
 /ccvs/
  config.h.in, configure
 /ccvs/windows-NT/
  config.h, config.h.in, stamp-chi

Log:
 Regenerated.

breaks the Windows build since Microsoft does NOT provide "sys/cdefs.h"
implementation.

CVS Project compiles primarily with Visual Studio 6.0 on Windows 2000.

> Cheers,

Ditto,

> Derek

Conrad

Configuration: libcvs - Win32 Debug
Compiling...
glob.c
h:\conrad\projects\cvs-1.12\lib\glob.h(29) : fatal error C1083: Cannot open 
include file: 'sys/cdefs.h': No such file or directory
Error executing cl.exe.

cvs.exe - 1 error(s), 0 warning(s)


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] New GNULIB glob module?

[Derek Price]

Paul Eggert wrote:

>Derek Price <[EMAIL PROTECTED]> writes:
>
>  
>
>>Fair enough, but why undo the change to glob.m4?  Shouldn't I just
>>change the target of the AC_DEFINE from MISSING_SYS_CDEFS_H to _SYS_CDEFS_H?
>>
>>
>
>Yes, you're right.
>
>Sorry, I'd forgotten the trick that I had suggested.  (This suggests
>that it deserves a nice fat comment.  :-)
>  
>

Done.  I added this comment to both glob_.h & glob.m4, with different
comment leaders, of course:

/* Note the reversal of the common HAVE_SYS_CDEFS_H idiom below.  In this
   way, #ifndef _SYS_CDEFS_H may be used to include  both when
   it has been checked for via the GNULIB configure test and found and when
   it has not been checked for, which we can presume means that the 
   GNULIB shares with GLIBC is being included as a system header and not as
   part of GNULIB, in which case  may be assumed.  */

I'm going to commit what I have as the new glob module soon if noone
says otherwise.  I and the CVS team made a few more minor changes to
make it work on Solaris, BSD, and Windows, but it is now compiling and
running on some 7 diverse platforms.

After that I will write up a ChangeLog entry for the glob-glibc2gnulib
diff and submit our changes back to the glibc team, unless someone here
who is used to working with them would like to take a go at the actual
submission part.  Perhaps it would be smoother if someone already known
to the glibc team introduced me and this patch?  Is the "definitive"
version of shared files usually in glibc, gnulib, or wherever someone
last remembered to merge when this happens?

Cheers,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

cvs client: refetching unpatchable files

[James Croxford]

Hello,

Don't if you can help but I am having a problem with CVS. This message keeps
appears on the log;

P CRMQU.src
cvs client: refetching unpatchable files
U CRMQU.src

It seems CVS is having a problem patching this file (amongst others),
however it then updates the file instead, which is obviously good in that we
get the end result.

The version of the CVS command we have is 1.11

I need to understand why a patch would fail, or at least some of the
possible reasons, and ideally would like to fix this so the patch works if
at all possible.

Is any one able to help? 

With Regards,

James Croxford*
 Disclaimer

This email transmission is confidential and intended solely for the
person or organization to whom it is addressed. If you are not the
intended recipient, you must not copy, distribute or disseminate the
information, or take any action in reliance of it. Any views expressed
in this message are those of the individual sender, except where the
sender specifically states them to be the views of any organization or
employer. If you have received this message in error, do not open any
attachment but please notify the sender (above) deleting this message
>from your system. Please rely on your own virus check no
responsibility is taken by the sender for any damage arising out of
any bug or virus infection.
*___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Module "run.c" Interface Standardized - Feature To Stable Branch

[Conrad T. Pino]

Hi All,

Derek modified "src/run.c" and prototypes in "src/cvs.h"
on both feature and stable branches which broke the:

stable Windows build
stable OS/2 build

feature Windows build
feature OS/2 build

To simplify maintaining the Windows build I standardized
the "run.c" interface by cloning the feature implementation
into the stable branch.  The "run.c" interface for the "os2",
"src" and "windows-NT" for both feature and stable are now
identical with the exception of "run_arg" which was removed
from feature and is implemented as a macro on stable.  The
removal of "run_arg" from stable is trivial and probably
pointless so I leave that for others to decide.

I committed "windows-NT/src.c" on feature and stable to fix
the Windows build by implementing a fix on feature which I
cloned to stable.  The feature and stable versions differ by
only 1 line as of this writing.

I committed "os2/run.c" and "src/run.c" on stable to complete
the stable interface standardization.  The Solaris 8 Intel
build on stable branch builds after the change.

The OS/2 feature and stable builds must both be broken since
neither implements the 2 new functions added to "src/run.c"
implementations.  The "os2/run.c" status is:

complaint with stable interface, missing functions

feature interface status unknown, missing functions

I'd like to know:

1. Who is able to run the OS/2 feature and stable builds?

2. If no one steps forward to assist with building should
we attempt a fix that can't be tested nevertheless?

Best regards,

Conrad Pino



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] New GNULIB glob module?

[Paul Eggert]

Derek Price <[EMAIL PROTECTED]> writes:

> Fair enough, but why undo the change to glob.m4?  Shouldn't I just
> change the target of the AC_DEFINE from MISSING_SYS_CDEFS_H to _SYS_CDEFS_H?

Yes, you're right.

Sorry, I'd forgotten the trick that I had suggested.  (This suggests
that it deserves a nice fat comment.  :-)


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs