Hello,
I have installed the git-1.5.1-1.mingw.exe from http://lilypond.org/git/binaries/mingw/.
On typing 'git' I get a message box saying :-
The procedure entry point libiconv could not be located in the dynamic link library libiconv-2.dll.
I cannot seem to find libiconv-2.dll anywhere either.
Hope you can help.
Many thanks in advance,
Aaron
Junio C HamanoRe: GIT on MinGW problem
"Aaron Gray" <angray@beeb.net> writes:
> Hello, > > I have installed the git-1.5.1-1.mingw.exe from > http://lilypond.org/git/binaries/mingw/. > > On typing 'git' I get a message box saying :- > > The procedure entry point libiconv could not be located in the > dynamic link library libiconv-2.dll. > > I cannot seem to find libiconv-2.dll anywhere either. > > Hope you can help. > > Many thanks in advance, > > Aaron
Even myself (who does not have anything to do with Windows machines) remembers seeing this exact thing in the past 12 hours:
article.gmane.org/gmane.comp.version-control.git/46962
Please check the archive before asking. Thanks.
Re: GIT on MinGW problem
>> I cannot seem to find libiconv-2.dll anywhere either. > > Even myself (who does not have anything to do with Windows > machines) remembers seeing this exact thing in the past 12 > hours: > > article.gmane.org/gmane.comp.version-control.git/46962 > > Please check the archive before asking. Thanks. >
Sorry.
The correct link is :-
http://sourceforge.net/project/downloading.php?group_id=23617&use_mirror=kent&filename=diffutils-2.8.7-1-dep.zip&19135304
renamed libiconv2.dll to libiconv-2.dll
Aaron
Han-Wen NienhuysRe: GIT on MinGW problem
Aaron Gray escreveu:
> Hello, > > I have installed the git-1.5.1-1.mingw.exe from > http://lilypond.org/git/binaries/mingw/. > > On typing 'git' I get a message box saying :- > > The procedure entry point libiconv could not be located in the > dynamic link library libiconv-2.dll. > > I cannot seem to find libiconv-2.dll anywhere either.
This should be fixed in
http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe
it should also set $PATH.
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Johannes SixtRe: GIT on MinGW problem
Han-Wen Nienhuys wrote:
> > Aaron Gray escreveu: > > Hello, > > > > I have installed the git-1.5.1-1.mingw.exe from > > http://lilypond.org/git/binaries/mingw/. > > > > On typing 'git' I get a message box saying :- > > > > The procedure entry point libiconv could not be located in the > > dynamic link library libiconv-2.dll. > > > > I cannot seem to find libiconv-2.dll anywhere either. > > This should be fixed in > > http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe > > it should also set $PATH.
I gave this some more testing and it turns out to be a well working toolset. Thank you very much!
There were still some issues remaining. These are the ones that should be fixable easily:
* git version reports just:
git version -dirty
Since git-gui parses the output of git version, but does not expect it to be of this format, and fails with an error message that it cannot parse the version.
* git without an correct git subcommand should list 20 or so commands, but it doesn't. The list is just empty.
* I personally think that the files should go into
$PROGRAMFILES/Git/{bin,share,lib}
instead of
$PROGRAMFILES/Git/usr/{bin,share,lib}The more difficult to solve problems are:
* git-gui and gitk don't work out of the box because they have the path to wish hardcoded. They can't be started from CMD at all. I have written wrappers gitk.cmd and git-gui.cmd with these 2 lines:
@echo off start wish84 D:/MSYS/1.0/git/bin/gitk %*
But as you can see, the path is still hard-coded (but it is good enough for me for the moment).
* perl scripts like git-remote contain a hard-coded path to the installation directory and don't work for this reason.
-- Hannes
Re: GIT on MinGW problem
On 5/25/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Han-Wen Nienhuys wrote: > > > > Aaron Gray escreveu: > > > Hello, > > > > > > I have installed the git-1.5.1-1.mingw.exe from > > > http://lilypond.org/git/binaries/mingw/. > > > > > > On typing 'git' I get a message box saying :- > > > > > > The procedure entry point libiconv could not be located in the > > > dynamic link library libiconv-2.dll. > > > > > > I cannot seem to find libiconv-2.dll anywhere either. > > > > This should be fixed in > > > > http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe > > > > it should also set $PATH. > > I gave this some more testing and it turns out to be a well working > toolset. Thank you very much! > > There were still some issues remaining. These are the ones that should > be fixable easily: > > * git version reports just: > > git version -dirty > > Since git-gui parses the output of git version, but does not expect it > to be of this format, and fails with an error message that it cannot > parse the version. >
Yes, an error message at startup is shown also with qgit.
Also 'git status' seems to have some issues.
Marco
Johannes SchindelinRe: GIT on MinGW problem
Hi,
On Fri, 25 May 2007, Johannes Sixt wrote:
> * I personally think that the files should go into
>
> $PROGRAMFILES/Git/{bin,share,lib}
> instead of
> $PROGRAMFILES/Git/usr/{bin,share,lib}Agree. It is trivial, but it will help others. It might also be a good idea to have a shortcut in "$PF/Git/Git Gui.lnk" to the git gui (once it is working, that is).
> * git-gui and gitk don't work out of the box because they have the path > to wish hardcoded. They can't be started from CMD at all. I have written > wrappers gitk.cmd and git-gui.cmd with these 2 lines: > > @echo off > start wish84 D:/MSYS/1.0/git/bin/gitk %* > > But as you can see, the path is still hard-coded (but it is good enough > for me for the moment).
I'd also like to see bash, perl and wish bundled with the install (Windows lusers are so used to one big install package, so it is an _advantage_ to have a bigger download).
> * perl scripts like git-remote contain a hard-coded path to the > installation directory and don't work for this reason.
GITPERLLIB should be set from the wrapper script, I think.
Ciao, Dscho
Johannes SixtRe: GIT on MinGW problem
Johannes Schindelin wrote:
> On Fri, 25 May 2007, Johannes Sixt wrote: > > * perl scripts like git-remote contain a hard-coded path to the > > installation directory and don't work for this reason. > > GITPERLLIB should be set from the wrapper script, I think.
The clean way is certainly to derive the directory from $0:
use lib $0 =~ /^(.*)([\/\\]+[^\/\\]*){2}$/ ? ("$1/lib") : ();(although I'm not sure whether this would work during 'make test').
-- Hannes
Han-Wen NienhuysRe: GIT on MinGW problem
Johannes Schindelin escreveu:
> Hi,
>
> On Fri, 25 May 2007, Johannes Sixt wrote:
>
>> * I personally think that the files should go into
>>
>> $PROGRAMFILES/Git/{bin,share,lib}
>> instead of
>> $PROGRAMFILES/Git/usr/{bin,share,lib}
>
> Agree. It is trivial, but it will help others. It might also be a good
> idea to have a shortcut in "$PF/Git/Git Gui.lnk" to the git gui (once it
> is working, that is).
>
>> * git-gui and gitk don't work out of the box because they have the path
>> to wish hardcoded. They can't be started from CMD at all. I have written
>> wrappers gitk.cmd and git-gui.cmd with these 2 lines:
>>
>> @echo off
>> start wish84 D:/MSYS/1.0/git/bin/gitk %*
>>
>> But as you can see, the path is still hard-coded (but it is good enough
>> for me for the moment).
>
> I'd also like to see bash, perl and wish bundled with the install (Windows Where is the info on the wish and bash port to Mingw?
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Johannes SchindelinRe: GIT on MinGW problem
Hi,
[before answering: a big thank you, Han-Wen, for doing that work. I think it is very valuable, especially because except Johannes Sixt, I have yet to encounter a person wanting "naive" Windows Git, but not hiding under the next rock when it comes to work on it.]
On Sat, 26 May 2007, Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu:
> >
> > On Fri, 25 May 2007, Johannes Sixt wrote:
> >
> >> * I personally think that the files should go into
> >>
> >> $PROGRAMFILES/Git/{bin,share,lib}
> >> instead of
> >> $PROGRAMFILES/Git/usr/{bin,share,lib}
> >
> > Agree. It is trivial, but it will help others. It might also be a good
> > idea to have a shortcut in "$PF/Git/Git Gui.lnk" to the git gui (once it
> > is working, that is).
> >
> >> * git-gui and gitk don't work out of the box because they have the path
> >> to wish hardcoded. They can't be started from CMD at all. I have written
> >> wrappers gitk.cmd and git-gui.cmd with these 2 lines:
> >>
> >> @echo off
> >> start wish84 D:/MSYS/1.0/git/bin/gitk %*
> >>
> >> But as you can see, the path is still hard-coded (but it is good enough
> >> for me for the moment).
> >
> > I'd also like to see bash, perl and wish bundled with the install (Windows
>
> Where is the info on the wish and bash port to Mingw?I recently compiled tcl and tk from scratch on MinGW. (No cross-compile.) Worked out of the box:
http://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz http://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz
(Now, if only Python worked like that...)
There's a bash src in the Snapshot package of MinGW:
http://prdownloads.sf.net/mingw/bash-2.05b-MSYS-src.tar.bz2?download
Ciao, Dscoh
Han-Wen NienhuysRe: GIT on MinGW problem
Johannes Schindelin escreveu:
> I recently compiled tcl and tk from scratch on MinGW. (No cross-compile.) > Worked out of the box: > > http://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz > http://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz >
GCC barfs on:
((Tcl_Obj **) objv) += (async + 3);
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Johannes SchindelinRe: GIT on MinGW problem
Hi,
On Sun, 27 May 2007, Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu: > > > I recently compiled tcl and tk from scratch on MinGW. (No cross-compile.) > > Worked out of the box: > > > > http://prdownloads.sourceforge.net/tcl/tcl8.4.14-src.tar.gz > > http://prdownloads.sourceforge.net/tcl/tk8.4.14-src.tar.gz > > > > GCC barfs on: > > ((Tcl_Obj **) objv) += (async + 3);
Ah yes, I was using MinGW's own GCC, which is GCC 3.something.
It is a new "feature" of GCC 4.x to disallow constructs like these. (Probably because GCC people think that other people are not intelligent enough to understand such constructs, and therefore prohibit their use.)
Ciao, Dscho
Han-Wen NienhuysRe: GIT on MinGW problem
Johannes Schindelin escreveu:
>> ((Tcl_Obj **) objv) += (async + 3); > > Ah yes, I was using MinGW's own GCC, which is GCC 3.something. > > It is a new "feature" of GCC 4.x to disallow constructs like these. > (Probably because GCC people think that other people are not intelligent > enough to understand such constructs, and therefore prohibit their use.)
I very much doubt that. GCC uses type information to determine whether pointers might be aliased. I think disallowing such constructs helps with compiler optimization.
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
NixRe: GIT on MinGW problem
On 27 May 2007, Han-Wen Nienhuys said:
> Johannes Schindelin escreveu: > >>> ((Tcl_Obj **) objv) += (async + 3); >> >> Ah yes, I was using MinGW's own GCC, which is GCC 3.something. >> >> It is a new "feature" of GCC 4.x to disallow constructs like these. >> (Probably because GCC people think that other people are not intelligent >> enough to understand such constructs, and therefore prohibit their use.) > > I very much doubt that. GCC uses type information to determine whether > pointers might be aliased. I think disallowing such constructs helps with > compiler optimization.
Actually it was simply too difficult to maintain this extension over the C and C++ parser rewrites in the early 4.x timeline. (Also, IIRC, it had some *nasty* ambiguities, especially in C++.)
-- `On a scale of one to ten of usefulness, BBC BASIC was several points ahead of the competition, scoring a relatively respectable zero.' --- Peter Corlett
Han-Wen NienhuysRe: GIT on MinGW problem
Johannes Schindelin escreveu:
> There's a bash src in the Snapshot package of MinGW: > > http://prdownloads.sf.net/mingw/bash-2.05b-MSYS-src.tar.bz2?download
this thoroughly confuses me.
Does it require MSYS? If yes, where can I find the MSYS source code?
What does it mean that:
However, it is important to remember that NO executables other than what ships with MSYS should be placed in the MSYS " bin" subdirectory. Therefore, do not attempt to "merge" the two packages. (http://www.mingw.org/mingwfaq.shtml#faq-msys)
If this is true, this will mess up my installers.
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Re: GIT on MinGW problem
> Han-Wen Nienhuys wrote:
>>
>> Aaron Gray escreveu:
>> > Hello,
>> >
>> > I have installed the git-1.5.1-1.mingw.exe from
>> > http://lilypond.org/git/binaries/mingw/.
>> >
>> > On typing 'git' I get a message box saying :-
>> >
>> > The procedure entry point libiconv could not be located in the
>> > dynamic link library libiconv-2.dll.
>> >
>> > I cannot seem to find libiconv-2.dll anywhere either.
>>
>> This should be fixed in
>>
>> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe
>>
>> it should also set $PATH.
>
> I gave this some more testing and it turns out to be a well working
> toolset. Thank you very much!
>
> There were still some issues remaining. These are the ones that should
> be fixable easily:
>
> * git version reports just:
>
> git version -dirty
>
> Since git-gui parses the output of git version, but does not expect it
> to be of this format, and fails with an error message that it cannot
> parse the version.
>
> * git without an correct git subcommand should list 20 or so commands,
> but it doesn't. The list is just empty.
>
> * I personally think that the files should go into
>
> $PROGRAMFILES/Git/{bin,share,lib}
> instead of
> $PROGRAMFILES/Git/usr/{bin,share,lib}
>
> The more difficult to solve problems are:
>
> * git-gui and gitk don't work out of the box because they have the path
> to wish hardcoded. They can't be started from CMD at all. I have written
> wrappers gitk.cmd and git-gui.cmd with these 2 lines:
>
> @echo off
> start wish84 D:/MSYS/1.0/git/bin/gitk %*
>
> But as you can see, the path is still hard-coded (but it is good enough
> for me for the moment).
>
> * perl scripts like git-remote contain a hard-coded path to the
> installation directory and don't work for this reason.Are git init and git clone working for you ?
Aaron
Han-Wen NienhuysRe: GIT on MinGW problem
Johannes Sixt escreveu:
>> >> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe >> >> it should also set $PATH. > > I gave this some more testing and it turns out to be a well working > toolset. Thank you very much! > > There were still some issues remaining. These are the ones that should > be fixable easily: > > * git version reports just: > > git version -dirty > > Since git-gui parses the output of git version, but does not expect it > to be of this format, and fails with an error message that it cannot > parse the version.
My biggest problem is that the makefiles of git are an unmitigated disaster, and there seems to be little interest in solving this problem. For example, my suggestion to introduce autoconf was met with derision. Most of the effort was patching out makefile parts that made my life harder. I may have patched the version part out as well.
In this, part of the pain is that Git tries to guess the version number by itself in a complicated way. It would be easiest if I could just specify the version number externally. In that case I can sync the installer version number (1.5.1-2 in this case) and the version that git reports.
> * git without an correct git subcommand should list 20 or so commands, > but it doesn't. The list is just empty.
there was a problem in generate cmd list, (I have sort in /bin/ ). I recommend to add
set -u -v
to all shell scripts so this doesn't go unnoticed.
> * I personally think that the files should go into
>
> $PROGRAMFILES/Git/{bin,share,lib}
> instead of
> $PROGRAMFILES/Git/usr/{bin,share,lib}
>
> The more difficult to solve problems are:I understand, but it makes my life a lot more difficult.
> * git-gui and gitk don't work out of the box because they have the path > to wish hardcoded. They can't be started from CMD at all. I have written > wrappers gitk.cmd and git-gui.cmd with these 2 lines: > > @echo off > start wish84 D:/MSYS/1.0/git/bin/gitk %* > > But as you can see, the path is still hard-coded (but it is good enough > for me for the moment).
The only solution is to x-compile wish and include it as well. I need several strong drinks to start trying this. Is there a MinGW wish port?
> * perl scripts like git-remote contain a hard-coded path to the > installation directory and don't work for this reason.
I actually commented out most perl stuff because the Makefile is just too spaghetti-ish. I seem to have forgotten commenting out git-remote.
I thought the policy was to abandon Perl scripts for git commands?
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Johannes SchindelinRe: GIT on MinGW problem
Hi,
On Sat, 26 May 2007, Han-Wen Nienhuys wrote:
> Johannes Sixt escreveu: > >> > >> http://lilypond.org/git/binaries/mingw/git-1.5.1-2.mingw.exe > >> > >> it should also set $PATH. > > > > I gave this some more testing and it turns out to be a well working > > toolset. Thank you very much! > > > > There were still some issues remaining. These are the ones that should > > be fixable easily: > > > > * git version reports just: > > > > git version -dirty > > > > Since git-gui parses the output of git version, but does not expect it > > to be of this format, and fails with an error message that it cannot > > parse the version. > > My biggest problem is that the makefiles of git are an unmitigated > disaster, and there seems to be little interest in solving this > problem. For example, my suggestion to introduce autoconf was met with > derision.
Well, I would not call it derision. But many people have had bad experience with that big mess which is autoconf, so we were more than reluctant to do it.
In the meantime, we do have a configure.ac, though. In general, you do not have to run it, but you can if "make" does not work out of the box.
I have to admit that it is unclear to me what are the problems with the Makefile with regards to gub. I think I will just bite the apple, and download that beast to try it myself.
> In this, part of the pain is that Git tries to guess the version number > by itself in a complicated way.
Yes, I never understood that myself why it has to be so complicated. But then, it did not make _my_ life hard, so I did not care.
> I thought the policy was to abandon Perl scripts for git commands?
Alas, no. We even have picked up a few since.
OTOH, it _is_ a nice thing to protohype the new commands as shell or perl scripts. When they stabilize enough, convert them to builtins.
There are exactly 4 perl scripts left that I regularly use:
add--interactive, cvsimport, remote and svn.
I somehow have the feeling that it is not worth the effort to convert cvsimport and svn. With add--interactive, I think it's better to leave it as is before Junio goes on another "what have I done? why did I have to add _this_?" spree.
But remote will soon be the center of my crosshairs.
Ciao, Dscho
Junio C HamanoRe: GIT on MinGW problem
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> In this, part of the pain is that Git tries to guess the version number >> by itself in a complicated way. > > Yes, I never understood that myself why it has to be so complicated. But > then, it did not make _my_ life hard, so I did not care.
"echo "MyVersionNumber" >version && make"?
> OTOH, it _is_ a nice thing to protohype the new commands as shell or perl > scripts. When they stabilize enough, convert them to builtins.
Protohype is a nice word. Throw out a half-working stuff and advertise it as the best thing since sliced bread even before it starts to being useful ;-)
> There are exactly 4 perl scripts left that I regularly use: > > add--interactive, cvsimport, remote and svn. > > I somehow have the feeling that it is not worth the effort to convert > cvsimport and svn. With add--interactive, I think it's better to leave it > as is before Junio goes on another "what have I done? why did I have to > add _this_?" spree.
I do not follow you here.
> But remote will soon be the center of my crosshairs.
I am afraid that it might be a bit premature.
I've been hoping that we can make git-clone a thin wrapper around init/remote/fetch/checkout. For one thing, we would want to split the separate-remotes layout and bareness to create "mirror" (I called it "pure" previously, but this is really a mirror) layout for git-clone, among other things, and that kind of enhancements would need to be done inside git-remote.
Johannes SchindelinRe: GIT on MinGW problem
Hi,
On Sat, 26 May 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > >> In this, part of the pain is that Git tries to guess the version number > >> by itself in a complicated way. > > > > Yes, I never understood that myself why it has to be so complicated. But > > then, it did not make _my_ life hard, so I did not care. > > "echo "MyVersionNumber" >version && make"?
Good to know!
> > OTOH, it _is_ a nice thing to protohype the new commands as shell or perl > > scripts. When they stabilize enough, convert them to builtins. > > Protohype is a nice word. Throw out a half-working stuff and > advertise it as the best thing since sliced bread even before it > starts to being useful ;-)
It started out as a typo. But then I liked it so much that I kept it ;-)
> > With add--interactive, I think it's better to leave it [...] > > I do not follow you here.
You mentioned several times that you were unsure if add--interactive was a good idea. But I like it very much.
> > > But remote will soon be the center of my crosshairs. > > I am afraid that it might be a bit premature. > > I've been hoping that we can make git-clone a thin wrapper > around init/remote/fetch/checkout. For one thing, we would want > to split the separate-remotes layout and bareness to create > "mirror" (I called it "pure" previously, but this is really a > mirror) layout for git-clone, among other things, and that kind > of enhancements would need to be done inside git-remote.
Fair enough.
Ciao, Dscho
Han-Wen NienhuysRe: GIT on MinGW problem
Johannes Schindelin escreveu:
>>> * git version reports just: >>> >>> git version -dirty >>> >>> Since git-gui parses the output of git version, but does not expect it >>> to be of this format, and fails with an error message that it cannot >>> parse the version. >> My biggest problem is that the makefiles of git are an unmitigated >> disaster, and there seems to be little interest in solving this >> problem. For example, my suggestion to introduce autoconf was met with >> derision. > > Well, I would not call it derision. But many people have had bad > experience with that big mess which is autoconf, so we were more than > reluctant to do it.
autoconf is not that big a mess, but it is a macrolanguage, which does come with its pitfalls. Automake and libtool are the messy things, and I prefer to stay away from them as far as possible.
The point of autoconf is to generate a hyper-portable script that deals with all the different flavors of shell breakage. For the user it simplifies compiling packages enormously, which IMO should be the guiding concern if you like to have users.
For a pretty run-of-the-mill tool like git (dependency wise), it should be easy to write a working configure.in.
My favorite approach is: use autoconf to generate
- config.h - config.make
All settings that force recompile should be in config.h, and standard C methods to track dependencies will take care of the recompilation when anything changes. The main Makefile includes config.make, and contains all configurable settings. The Makefile only needs to be edited by developers. Require GNU Make so you can write sane makefiles.
Instead, we have a Makefile that relies on an esoteric combination of perl and shell scripting inside Makefiles.
Also, the Makefile says.
# Shell quote (do not use $(call) to accommodate ancient setups);
I think it would be better to have a clearly defined list of optional and required dependencies with version numbers, and then stand by that. For example, Make uses a completely autoconf/libtool based compile process, and is easy to compile. I think it would be reasonable to require a recent make, say 3.80, and then use its features.
> In the meantime, we do have a configure.ac, though. In general, you do not > have to run it, but you can if "make" does not work out of the box. > > I have to admit that it is unclear to me what are the problems with the > Makefile with regards to gub. I think I will just bite the apple, and > download that beast to try it myself.
>From what I recall, it tries to be too clever in detecting changes
of the make command line, forcing a recompile (possibly with erroneous paths) during the
make install
I might be mistaken, though. I tried to get something up as fast as possible.
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Jakub NarebskiRe: GIT on MinGW problem
Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu:
>>>> * git version reports just: >>>> >>>> git version -dirty >>>> >>>> Since git-gui parses the output of git version, but does not expect it >>>> to be of this format, and fails with an error message that it cannot >>>> parse the version. >>> My biggest problem is that the makefiles of git are an unmitigated >>> disaster, and there seems to be little interest in solving this >>> problem. For example, my suggestion to introduce autoconf was met with >>> derision. >> >> Well, I would not call it derision. But many people have had bad >> experience with that big mess which is autoconf, so we were more than >> reluctant to do it. > > autoconf is not that big a mess, but it is a macrolanguage, which does > come with its pitfalls. Automake and libtool are the messy things, > and I prefer to stay away from them as far as possible. > > The point of autoconf is to generate a hyper-portable script that > deals with all the different flavors of shell breakage. For the user > it simplifies compiling packages enormously, which IMO should be the > guiding concern if you like to have users. > > For a pretty run-of-the-mill tool like git (dependency wise), it > should be easy to write a working configure.in. > > My favorite approach is: use autoconf to generate > > - config.h > > - config.make > > All settings that force recompile should be in config.h, and standard > C methods to track dependencies will take care of the recompilation > when anything changes. The main Makefile includes config.make, and > contains all configurable settings. The Makefile only needs to be > edited by developers. Require GNU Make so you can write sane > makefiles.
Actually we do have configure.ac script; ./configure (result of "make configure") is not distributed in the tarball I think. It generates file named not config.make, but config.mak.autogen. By the way, the .autogen suffix is to distinguish ./configure generated file from handmade user configureation, but I have no idea why it is config.mak not config.make. But there is no config.h -- we do not rely on automake and autoheader.
If you are well wersed in autoconf, feel free to improve our configure.ac script.
> Instead, we have a Makefile that relies on an esoteric combination of > perl and shell scripting inside Makefiles.
The idea is to be able to get reasonable defaults (depending on system of course) without needing autoconf, and running quite long on some platform ./configure script detection...
-- Jakub Narebski Warsaw, Poland ShadeHawk on #git
Han-Wen NienhuysRe: GIT on MinGW problem
Jakub Narebski escreveu:
>> Instead, we have a Makefile that relies on an esoteric combination of >> perl and shell scripting inside Makefiles. > > The idea is to be able to get reasonable defaults (depending on system of
This saves the user on Linux or similar platform one ./configure call. For the rest it means editing makefiles. I'm not sure if that is an improvement over the standard
configure ; make ; make install
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Shawn O. PearceRe: GIT on MinGW problem
Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
> Jakub Narebski escreveu: > > >> Instead, we have a Makefile that relies on an esoteric combination of > >> perl and shell scripting inside Makefiles. > > > > The idea is to be able to get reasonable defaults (depending on system of > > This saves the user on Linux or similar platform one ./configure call. For > the rest it means editing makefiles. I'm not sure if that is an improvement > over the standard > > configure ; make ; make install
[side note: can you please not send both To the list and CC the list on the same message? Pick one, we're all getting two copies of messages from you.]
On systems like Cygwin the fork+exec overheads are very high; running a "simple" configure script can take longer than it takes me to compile Git from scratch. Editing config.mak is quite easy; so is passing your choices on the command line to `make install`.
Personally I find:
make NO_CURL=1 install
easier than:
./configure --without-curl && make install
-- Shawn.
Han-Wen NienhuysRe: GIT on MinGW problem
Shawn O. Pearce escreveu:
> > On systems like Cygwin the fork+exec overheads are very high; > running a "simple" configure script can take longer than it > takes me to compile Git from scratch. Editing config.mak is > quite easy; so is passing your choices on the command line to > `make install`. > > Personally I find: > > make NO_CURL=1 install > > easier than: > > ./configure --without-curl && make install
NO_CURL is a nonstandard option. Every package does it differently, so this requires users to delve through either INSTALL or Makefile.
A well written configure script is able to detect presence of a linkable libcurl.
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Steven GrimmRe: GIT on MinGW problem
Han-Wen Nienhuys wrote:
>> On systems like Cygwin the fork+exec overheads are very high > A well written configure script is able to detect presence > of a linkable libcurl. >
IMO the reasons configure is so unwieldy, at least as it's set up in most open source projects, are that a) it spends 95% of its time checking for things that basically never vary (yes, I have stdlib.h, thank you) and that b) it doesn't remember the results from previous runs on the same host (I'm just changing the install path; my ints won't have stopped being 32 bits as a result.) I wonder if we could satisfy most people with a configure script -- maybe not based on autoconf -- that is limited in scope to just the things that are currently tweakable in the git Makefile.
If configure ran only, say, 10-15 tests, I bet the fork+exec overhead on Cygwin would be perfectly tolerable.
-Steve
Jakub NarebskiRe: GIT on MinGW problem
On Sun, 27 May 2007, Steven Grimm wrote:
> Han-Wen Nienhuys wrote: >> Shawn O. Pearce escreveu: >>> >>> On systems like Cygwin the fork+exec overheads are very high >> >> A well written configure script is able to detect presence >> of a linkable libcurl. > > IMO the reasons configure is so unwieldy, at least as it's set up in > most open source projects, are that a) it spends 95% of its time > checking for things that basically never vary (yes, I have stdlib.h, > thank you) and that b) it doesn't remember the results from previous > runs on the same host (I'm just changing the install path; my ints won't > have stopped being 32 bits as a result.)
./configure _can_ cache tests results:
$ ./configure --help
[...]
--cache-file=FILE cache test results in FILE [disabled]
-C, --config-cache alias for `--cache-file=config.cache'but it does not do this, and does not check chache by default. Of course tests have to be written to make use of cache, IIRC...
> I wonder if we could satisfy > most people with a configure script -- maybe not based on autoconf -- > that is limited in scope to just the things that are currently tweakable > in the git Makefile.
The problem with handcrafted configure script lies in the portability of it. There was an attempt to add such script, IIRC based on mplayer's configure.sh script, but it turned out it was not portable enough. The conclusion was that sice so many manhours were put into making autoconf generate ultra-portable ./configure shell script, it would be better to use it.
> If configure ran only, say, 10-15 tests, I bet the fork+exec overhead on > Cygwin would be perfectly tolerable.
That's not only fork+exec, that is also the fact that large number of tests relies on compiling snippets of code...
P.S. What do you think about separating the guessing appropriate values of build variables based on uname to separate file config.mak.guess, included in Makefile?
-- Jakub Narebski Poland
Han-Wen NienhuysRe: GIT on MinGW problem
Jakub Narebski escreveu:
> On Sun, 27 May 2007, Steven Grimm wrote: >> Han-Wen Nienhuys wrote: >>> Shawn O. Pearce escreveu: >>>> On systems like Cygwin the fork+exec overheads are very high >>> A well written configure script is able to detect presence >>> of a linkable libcurl. >> IMO the reasons configure is so unwieldy, at least as it's set up in >> most open source projects, are that a) it spends 95% of its time >> checking for things that basically never vary (yes, I have stdlib.h, >> thank you) and that b) it doesn't remember the results from previous >> runs on the same host (I'm just changing the install path; my ints won't >> have stopped being 32 bits as a result.) > > ./configure _can_ cache tests results: > > $ ./configure --help > [...] > --cache-file=FILE cache test results in FILE [disabled] > -C, --config-cache alias for `--cache-file=config.cache' > > but it does not do this, and does not check chache by default. Of course > tests have to be written to make use of cache, IIRC...
Slowness is a misguided argument as well. Yes, configure is slow, but you only have to run it if configure.in , config.h.in or config.make.in chagnes. And that doesn't happen very often during development.
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Johannes SchindelinRe: GIT on MinGW problem
Hi,
On Sun, 27 May 2007, Han-Wen Nienhuys wrote:
> Jakub Narebski escreveu: > > On Sun, 27 May 2007, Steven Grimm wrote: > >> Han-Wen Nienhuys wrote: > >>> Shawn O. Pearce escreveu: > >>>> On systems like Cygwin the fork+exec overheads are very high > >>> A well written configure script is able to detect presence > >>> of a linkable libcurl. > >> IMO the reasons configure is so unwieldy, at least as it's set up in > >> most open source projects, are that a) it spends 95% of its time > >> checking for things that basically never vary (yes, I have stdlib.h, > >> thank you) and that b) it doesn't remember the results from previous > >> runs on the same host (I'm just changing the install path; my ints won't > >> have stopped being 32 bits as a result.) > > > > ./configure _can_ cache tests results: > > > > $ ./configure --help > > [...] > > --cache-file=FILE cache test results in FILE [disabled] > > -C, --config-cache alias for `--cache-file=config.cache' > > > > but it does not do this, and does not check chache by default. Of course > > tests have to be written to make use of cache, IIRC... > > Slowness is a misguided argument as well. Yes, configure is slow, but > you only have to run it if configure.in , config.h.in or config.make.in > chagnes. And that doesn't happen very often during development.
Slowness is a good argument. The config does change from time to time (you should know, IICC LilyPond had 36 changes in configure.in through 2006). And it is annoying.
Especially when you are trying to debug ./configure.
Ciao, Dscho
Han-Wen NienhuysRe: GIT on MinGW problem
Johannes Schindelin escreveu:
>>> but it does not do this, and does not check chache by default. Of course >>> tests have to be written to make use of cache, IIRC... >> Slowness is a misguided argument as well. Yes, configure is slow, but >> you only have to run it if configure.in , config.h.in or config.make.in >> chagnes. And that doesn't happen very often during development. > > Slowness is a good argument. The config does change from time to time (you > should know, IICC LilyPond had 36 changes in configure.in through 2006).
Compared to the 100 recompiles during a typical debug/compile day, that's not very significant, IMO.
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Johannes SchindelinRe: GIT on MinGW problem
Hi,
On Sun, 27 May 2007, Han-Wen Nienhuys wrote:
> Jakub Narebski escreveu: > > >> Instead, we have a Makefile that relies on an esoteric combination of > >> perl and shell scripting inside Makefiles. > > > > The idea is to be able to get reasonable defaults (depending on system > > of > > This saves the user on Linux or similar platform one ./configure call.
It works on Linux, Cygwin, MinGW, last time I checked MacOSX, IRIX, and I imagine Solaris, AIX and even other platforms, out of the box.
> For the rest it means editing makefiles. I'm not sure if that is an > improvement over the standard > > configure ; make ; make install
ATM you have to do autoconf before that. But that should work, really.
Ciao, Dscho
Han-Wen NienhuysRe: GIT on MinGW problem
Han-Wen Nienhuys escreveu:
> The only solution is to x-compile wish and include it as well. I need several > strong drinks to start trying this. Is there a MinGW wish port?
It turns out that spending a night in a brazilian/japanese karaoke bar where thumping disco beats of the sadly deserted dance area permeates the bleary out-of-tune portuguese singing of hormonally driven women did enough to melt my mind.
There is a 1.5.2-3 installer which includes a cross-compiled tcltk.
http://lilypond.org/git/binaries/mingw/
What is the proper way to have the 'gitk' command start up with wish automatically?
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Han-Wen NienhuysGIT on MinGW, with tcltk for gitk
Han-Wen Nienhuys escreveu:
> There is a 1.5.2-3 installer which includes a cross-compiled tcltk. > > http://lilypond.org/git/binaries/mingw/ > > What is the proper way to have the 'gitk' command start up with wish > automatically?
I've just uploaded 1.5.2-5, which also writes a gitk.bat file, containing proper paths. However, I can't get it working in Wine. Any windows user that cares to test?
http://lilypond.org/git/binaries/mingw/git-1.5.2-5.mingw.exe
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Re: GIT on MinGW, with tcltk for gitk
> Han-Wen Nienhuys escreveu: >> There is a 1.5.2-3 installer which includes a cross-compiled tcltk. >> >> http://lilypond.org/git/binaries/mingw/ >> >> What is the proper way to have the 'gitk' command start up with wish >> automatically? > > I've just uploaded 1.5.2-5, which also writes a gitk.bat file, containing > proper paths. However, I can't get it working in Wine. Any windows user > that cares to test? > > http://lilypond.org/git/binaries/mingw/git-1.5.2-5.mingw.exe >
git clone or git-clone are not accessable still.
C:\Work\test>git init warning: templates not found C:/Program Files/Git/usr/bin@template_dir@ Initialized empty Git repository in .git/
Aaron
Han-Wen NienhuysRe: GIT on MinGW, with tcltk for gitk
Aaron Gray escreveu:
> C:\Work\test>git init > warning: templates not found C:/Program Files/Git/usr/bin@template_dir@ > Initialized empty Git repository in .git/ > > Aaron
Thanks for the report. Can you try again with 1.5.2-7 ? It should be available in a few minutes.
Also, can you tell me if gitk.bat works for you?
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Re: GIT on MinGW, with tcltk for gitk
> Aaron Gray escreveu: > >> C:\Work\test>git init >> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@ >> Initialized empty Git repository in .git/ >> >> Aaron > > Thanks for the report. Can you try again with 1.5.2-7 ? It should be > available > in a few minutes.
Okay, I'm up for all the testing thats needed. Just dont know the territory that well though, as I am a Windozer :)
> Also, can you tell me if gitk.bat works for you?
Okay, I just type 'gitk' ?
And what happens ?
Thanks,
Aaron
Re: GIT on MinGW, with tcltk for gitk
>> Aaron Gray escreveu: >> >>> C:\Work\test>git init >>> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@ >>> Initialized empty Git repository in .git/ >>> >>> Aaron >> >> Thanks for the report. Can you try again with 1.5.2-7 ? It should be >> available >> in a few minutes. > > Okay, I'm up for all the testing thats needed. Just dont know the > territory that well though, as I am a Windozer :)
git init appears to work fine now, the template path is found.
git clone or git-clone is still not working.
'git clone' just gives a list of git's commands.
git-clone gives usual :-
C:\Work\test2>git-clone git://git.kernel.org/pub/scm/git/git.git 'git-clone' is not recognized as an internal or external command, operable program or batch file.
>> Also, can you tell me if gitk.bat works for you? > > Okay, I just type 'gitk' ?
C:\Work>gitk '"C:\Program Files\Git\usr\bin\wish.exe"' is not recognized as an internal or external command, operable program or batch file.
Theres a file called 'wish84.exe' under 'C:\Program Files\Git\usr\bin', but no wish.exe.
Aaron
Aaron
Han-Wen NienhuysRe: GIT on MinGW, with tcltk for gitk
2007/5/27, Aaron Gray <angray@beeb.net>:
> '"C:\Program Files\Git\usr\bin\wish.exe"' is not recognized as an internal > or external command, operable program or batch file. > > Theres a file called 'wish84.exe' under 'C:\Program Files\Git\usr\bin', but > no wish.exe.
can you edit this .bat to say wish84.exe iso. wish.exe ?
thnks,
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Re: GIT on MinGW, with tcltk for gitk
> 2007/5/27, Aaron Gray <angray@beeb.net>: > >> '"C:\Program Files\Git\usr\bin\wish.exe"' is not recognized as an >> internal >> or external command, operable program or batch file. >> >> Theres a file called 'wish84.exe' under 'C:\Program Files\Git\usr\bin', >> but >> no wish.exe. > > can you edit this .bat to say wish84.exe iso. wish.exe ?
Getting message box saying :-
child process exited abnormally
while executing
"close $refd"
(proceedure "readrefs" line 47)
invoked from within
"readrefs"
(file "C:\Program Files\Git\usr\bin\gitk line 6369):(
Aaron
Han-Wen NienhuysRe: GIT on MinGW, with tcltk for gitk
Aaron Gray escreveu:
>>> >>> Theres a file called 'wish84.exe' under 'C:\Program >>> Files\Git\usr\bin', but >>> no wish.exe. >> >> can you edit this .bat to say wish84.exe iso. wish.exe ? > > Getting message box saying :- > > child process exited abnormally > while executing > "close $refd" > (proceedure "readrefs" line 47) > invoked from within > "readrefs" > (file "C:\Program Files\Git\usr\bin\gitk line 6369) > > :(
It seems that tcltk was executed; Unfortunately, it does work flawlessly under wine, so there is little I can do. I invite windows experts to have a closer look.
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Re: GIT on MinGW - No symbolic links support
Bit of a dampener on GIT on MinGW :-
$ git clone git://git.kernel.org/pub/scm/git/git.git
Initialized empty Git repository in C:/MSYS/src/git/.git/
error: git-checkout-index: unable to create symlink RelNotes
(Function not implemented)No Symbolic links !
There are symbolic links provided by Windows by SFU (Services For Unix) apparently.
Aaron
Johannes SchindelinRe: GIT on MinGW - No symbolic links support
Hi,
On Sun, 27 May 2007, Aaron Gray wrote:
> Bit of a dampener on GIT on MinGW :- > > $ git clone git://git.kernel.org/pub/scm/git/git.git > Initialized empty Git repository in C:/MSYS/src/git/.git/ > error: git-checkout-index: unable to create symlink RelNotes (Function > not implemented) > > No Symbolic links ! > > There are symbolic links provided by Windows by SFU (Services For Unix) > apparently.
Does not work on FAT. Has lots of problems.
That's why Johannes Sixt pushed for core.symlinks, and got it. So maybe the templates should set core.symlinks=false?
Ciao, Dscho
Johannes SixtRe: GIT on MinGW - No symbolic links support
Johannes Schindelin wrote:
> > Hi, > > On Sun, 27 May 2007, Aaron Gray wrote: > > > Bit of a dampener on GIT on MinGW :- > > > > $ git clone git://git.kernel.org/pub/scm/git/git.git > > Initialized empty Git repository in C:/MSYS/src/git/.git/ > > error: git-checkout-index: unable to create symlink RelNotes (Function > > not implemented) > > > > No Symbolic links ! > > > > There are symbolic links provided by Windows by SFU (Services For Unix) > > apparently. > > Does not work on FAT. Has lots of problems. > > That's why Johannes Sixt pushed for core.symlinks, and got it. So maybe > the templates should set core.symlinks=false?
This setting should be placed into $(sysconfigdir)/gitconfig. I'll hack up something in the next days. The "challenge" is that $(sysconfigdir) must not be hardcoded (because the installation location is not known until runtime). A similar thing I have already done with $(template_dir).
-- Hannes
Han-Wen NienhuysRe: GIT on MinGW, with tcltk for gitk
Aaron Gray escreveu:
>>> Aaron Gray escreveu: >>> >>>> C:\Work\test>git init >>>> warning: templates not found C:/Program Files/Git/usr/bin@template_dir@ >>>> Initialized empty Git repository in .git/ >>>> >>>> Aaron >>> >>> Thanks for the report. Can you try again with 1.5.2-7 ? It should be >>> available >>> in a few minutes. >> >> Okay, I'm up for all the testing thats needed. Just dont know the >> territory that well though, as I am a Windozer :) > > git init appears to work fine now, the template path is found. > > git clone or git-clone is still not working. >
clone is a shell script. None of the shell scripts work; you'll have to install msys bash yourself for now.
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Johannes SixtRe: GIT on MinGW problem
Han-Wen Nienhuys wrote:
> Johannes Sixt escreveu: > > * git without an correct git subcommand should list 20 or so commands, > > but it doesn't. The list is just empty. > > there was a problem in generate cmd list, (I have sort in /bin/ ). I > recommend to add
Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the same as /bin/sort.
(For the curious ones: The MinGW port has to replace occurrences of 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be picked up in shell scripts, because the latter usually comes first in %PATH%^W$PATH. Same for 'find'.)
-- Hannes
Marius Storm-OlsenRe: GIT on MinGW problem
Johannes Sixt said the following on 29.05.2007 12:54:
> Han-Wen Nienhuys wrote: >> Johannes Sixt escreveu: >>> * git without an correct git subcommand should list 20 or so >>> commands, but it doesn't. The list is just empty. >> there was a problem in generate cmd list, (I have sort in /bin/ >> ). I recommend to add > > Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the > same as /bin/sort. > > (For the curious ones: The MinGW port has to replace occurrences of > 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be > picked up in shell scripts, because the latter usually comes first > in %PATH%^W$PATH. Same for 'find'.)
I get that here too, no matter what I set the mount point to be, and without the fstab file at all.
Also, the /bin/gitk.bat file should rather be
@"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %*
than the current hardcoded path. (Probably won't work with
command.com, but who uses that for development nowadays anyways, right ;-)-- .marius
Johannes SixtRe: GIT on MinGW problem
Marius Storm-Olsen wrote:
> > Johannes Sixt said the following on 29.05.2007 12:54: > > Han-Wen Nienhuys wrote: > >> Johannes Sixt escreveu: > >>> * git without an correct git subcommand should list 20 or so > >>> commands, but it doesn't. The list is just empty. > >> there was a problem in generate cmd list, (I have sort in /bin/ > >> ). I recommend to add > > > > Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the > > same as /bin/sort. > > > > (For the curious ones: The MinGW port has to replace occurrences of > > 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be > > picked up in shell scripts, because the latter usually comes first > > in %PATH%^W$PATH. Same for 'find'.) > > I get that here too, no matter what I set the mount point to be, and > without the fstab file at all.
When I inserted '/usr/bin/sort' I had checked for 'which sort' on my Linux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably the canonical path to sort on any *nix. Will change that. But is this also true for 'find'?
> Also, the /bin/gitk.bat file should rather be > @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %* > than the current hardcoded path. (Probably won't work with > command.com, but who uses that for development nowadays anyways, right ;-)
Nice trick! But don't try this at home without parental guidance! It fills your screen with recursive console window invocations of itself.
I put this into gitk.cmd (didn't try .bat):
@start wish84.exe "%~d0%~p0gitk" %*
assuming wish84 is in the PATH (which is probably a sane assumption because either it is part of the installer, in which case it should have set up the PATH, or you have Tcl/Tk installed for some other reason, in which case you will want to have it in the PATH, too).
Futhermore, I like to have the GUI sent into the background automatically and without opening another console window, hence, the use of 'start'.
-- Hannes
Han-Wen NienhuysRe: GIT on MinGW problem
2007/5/29, Johannes Sixt <J.Sixt@eudaptics.com>:
> > I get that here too, no matter what I set the mount point to be, and > > without the fstab file at all. > > When I inserted '/usr/bin/sort' I had checked for 'which sort' on my > Linux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably > the canonical path to sort on any *nix. Will change that. But is this > also true for 'find'?
I suggest that you add $PATH appropriately (prepending /bin and /usr/bin/ ) and then let the OS figure it out. The other option is to write an autoconf test to discover the proper path.
> > Also, the /bin/gitk.bat file should rather be > > @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %* > > than the current hardcoded path. (Probably won't work with > > command.com, but who uses that for development nowadays anyways, right ;-) > > Nice trick! But don't try this at home without parental guidance! It > fills your screen with recursive console window invocations of itself. > > I put this into gitk.cmd (didn't try .bat): > > @start wish84.exe "%~d0%~p0gitk" %* > > assuming wish84 is in the PATH (which is probably a sane assumption > because either it is part of the installer, in which case it should have > set up the PATH, or you have Tcl/Tk installed for some other reason, in > which case you will want to have it in the PATH, too). > > Futhermore, I like to have the GUI sent into the background > automatically and without opening another console window, hence, the use > of 'start'.
I'll have a look at this when I have time. What the hell is
%~d0%~p0
?
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Johannes SixtRe: GIT on MinGW problem
Han-Wen Nienhuys wrote:
> > 2007/5/29, Johannes Sixt <J.Sixt@eudaptics.com>: > > > > I get that here too, no matter what I set the mount point to be, and > > > without the fstab file at all. > > > > When I inserted '/usr/bin/sort' I had checked for 'which sort' on my > > Linux and it gave me /usr/bin/sort. Now I see that /bin/sort is probably > > the canonical path to sort on any *nix. Will change that. But is this > > also true for 'find'? > > I suggest that you add $PATH appropriately (prepending /bin and > /usr/bin/ ) and then > let the OS figure it out. The other option is to write an autoconf > test to discover the proper path.
'sort' (and 'find' for that matter) is not only used by the build scripts, but also by some shell scripts of the toolset. Hence, the path would have to be modified for each 'git foo' invocation, IOW, by git.exe itself. I don't like this solution.
The alternative, to force the user to put his $MSYSDIR/bin before $WINNT (which would require admin rights, btw, because the system's PATH must be modified), I like even less.
I've to think a bit more about this.
-- Hannes
Johannes SchindelinRe: GIT on MinGW problem
Hi,
On Tue, 29 May 2007, Marius Storm-Olsen wrote:
> Johannes Sixt said the following on 29.05.2007 12:54: > > Han-Wen Nienhuys wrote: > > > Johannes Sixt escreveu: > > > > * git without an correct git subcommand should list 20 or so > > > > commands, but it doesn't. The list is just empty. > > > there was a problem in generate cmd list, (I have sort in /bin/ > > > ). I recommend to add > > > > Strange. Here, MSYS aliases /usr to /, hence /usr/bin/sort is the > > same as /bin/sort. > > > > (For the curious ones: The MinGW port has to replace occurrences of > > 'sort' by '/usr/bin/sort', otherwise Windows's 'sort' would be > > picked up in shell scripts, because the latter usually comes first > > in %PATH%^W$PATH. Same for 'find'.) > > I get that here too, no matter what I set the mount point to be, and without > the fstab file at all. > > Also, the /bin/gitk.bat file should rather be > @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %* > than the current hardcoded path. (Probably won't work with command.com, but > who uses that for development nowadays anyways, right ;-)
We're open source, so we _can_ do better than leaving people stuck on older hardware behind.
And I don't know what this garbage means. (I checked with GMane, and it looks the same there.) I'd rather have something readable, even if it is slightly slower or has to be adjusted when installing.
Ciao, Dscho
Marius Storm-OlsenRe: GIT on MinGW problem
Johannes Schindelin said the following on 29.05.2007 14:11:
>> Also, the /bin/gitk.bat file should rather be >> @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %* than the current >> hardcoded path. (Probably won't work with command.com, but who >> uses that for development nowadays anyways, right ;-) > > We're open source, so we _can_ do better than leaving people stuck > on older hardware behind. > > And I don't know what this garbage means. (I checked with GMane, > and it looks the same there.) I'd rather have something readable, > even if it is slightly slower or has to be adjusted when > installing.
%~d0 = expands %0 to a drive letter only %~p0 = expands %0 to a path only
so, for
C:\foo\bar\baz\gitk.bat
%~d0%~p0gitk would expand to
C:\foo\bar\baz\gitkLooking at the docs for cmd's call (run 'help call'), I see now that
it can be written
%~dp0gitk
as well..Anyways, if people are critical to not supporting the command.com, then you could do something like the following. (Note that for command.com it would be the old behavior were you need to replace the path if you install Git somewhere else, while for cmd.exe users it will just work. I'm sure magic can be done to make it work with command.com as well, but I'll leave that up to someone else to play with):
--- @echo off REM This GOTO relies on the hack that command.com only supports REM 8 character labels, so it reads 'goto _Windows' goto :_WindowsNT
REM Command.com jumps here :_Windows wish84.exe "C:\Git\usr\bin\gitk" %1 %2 %3 %4 %5 %6 %7 %8 %9 REM NOTE! If you install Git in some other path, and use REM command.com, you need to replace the path above
goto :EOF
REM Cmd.exe jumps here :_WindowsNT start wish84.exe "%~dp0gitk" %*
:EOF
-- .marius
Johannes SixtRe: GIT on MinGW problem
Marius Storm-Olsen wrote:
> > Johannes Schindelin said the following on 29.05.2007 14:11: > >> Also, the /bin/gitk.bat file should rather be > >> @"%~d0%~p0wish84.exe" "%~d0%~p0gitk" %* than the current > >> hardcoded path. (Probably won't work with command.com, but who > >> uses that for development nowadays anyways, right ;-) > > > > We're open source, so we _can_ do better than leaving people stuck > > on older hardware behind. > > > > And I don't know what this garbage means. (I checked with GMane, > > and it looks the same there.) I'd rather have something readable, > > even if it is slightly slower or has to be adjusted when > > installing. > > %~d0 = expands %0 to a drive letter only > %~p0 = expands %0 to a path only > > so, for > C:\foo\bar\baz\gitk.bat > %~d0%~p0gitk would expand to > C:\foo\bar\baz\gitk > > Looking at the docs for cmd's call (run 'help call'), I see now that > it can be written > %~dp0gitk > as well..
But... the docs also say that this stuff is only available if command extensions are turned on. Are they on by default?
(I cannot tell because I remember faintly that I fiddled with the corresponding registry setting in the past, but don't know whether it was on or off at the beginning.)
-- Hannes
Marius Storm-OlsenRe: GIT on MinGW problem
Johannes Sixt said the following on 29.05.2007 15:24:
>> Looking at the docs for cmd's call (run 'help call'), I see now that >> it can be written >> %~dp0gitk >> as well.. > > But... the docs also say that this stuff is only available if command > extensions are turned on. Are they on by default? > > (I cannot tell because I remember faintly that I fiddled with the > corresponding registry setting in the past, but don't know whether it > was on or off at the beginning.)
Ok, MSDN says it on by default on XP, while other docs say its on by default without specifying any platforms. Also, it might be that the %~dp0 construct is only supported on later versions of the cmd extension too (I don't have NT 4, so I can't test this), so to be on the safe side you can do this:
---- @echo off REM This GOTO relies on the hack that command.com only supports REM 8 character labels, so it reads 'goto _Windows' goto :_WindowsNT
REM Command.com jumps here :_Windows wish84.exe "C:\Git\usr\bin\gitk" %1 %2 %3 %4 %5 %6 %7 %8 %9 REM NOTE! If you install Git in some other path, and use REM command.com, you need to replace the path above
goto :EOF
REM Cmd.exe jumps here
:_WindowsNT
if "%1" neq "ensureExt" (
REM Call the script again with cmd /X to explicitly turn on Command Extensions
%COMSPEC% /X /C "%0 ensureExt %*"
goto :EOF
)REM If our CMD Extension version is less than 2, we might not support the %~dp0
REM construct so, just do the normal _Windows call instead. (This should only
REM happen on old Windows NT 4, where the extension is not so sophisticated
if not cmdextversion 2 (
call :_Windows %2 %3 %4 %5 %6 %7 %8 %9
goto :EOF
)
start wish84.exe "%~dp0gitk" %2 %3 %4 %5 %6 %7 %8 %9:EOF
-- .marius
Johannes SchindelinRe: GIT on MinGW problem
Hi,
On Tue, 29 May 2007, Marius Storm-Olsen wrote:
> Looking at the docs for cmd's call (run 'help call'), [...]
Which one?
There are at least three different cmd.exe that _I_ encountered: NT4.0, 2000 and XP. All of them have different features. None of my scripts worked without _heavy_ workarounding on all of them.
But I think a .lnk file would be easier to create, and more portable, right?
Ciao, Dscho
Johannes SixtRe: GIT on MinGW problem
Johannes Schindelin wrote:
> There are at least three different cmd.exe that _I_ encountered: NT4.0, > 2000 and XP. All of them have different features. None of my scripts > worked without _heavy_ workarounding on all of them. > > But I think a .lnk file would be easier to create, and more portable, > right?
If:
1. there is a .lnk file named gitk.lnk with target for example:
D:\MSYS\1.0\mingw\bin\wish84.exe D:\MSYS\1.0\git\bin\gitk
2. you change PATHEXT to include '.LNK'.
then gitk can be invoked with varying arguments from CMD. I've tested this only on W2k. Point 2 looks hackish and dangerous to me.
-- Hannes
Nguyen Thai Ngoc DuyRe: GIT on MinGW problem
On 5/29/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Johannes Schindelin wrote: > > There are at least three different cmd.exe that _I_ encountered: NT4.0, > > 2000 and XP. All of them have different features. None of my scripts > > worked without _heavy_ workarounding on all of them. > > > > But I think a .lnk file would be easier to create, and more portable, > > right? > > If: > > 1. there is a .lnk file named gitk.lnk with target for example: > > D:\MSYS\1.0\mingw\bin\wish84.exe D:\MSYS\1.0\git\bin\gitk > > 2. you change PATHEXT to include '.LNK'. > > then gitk can be invoked with varying arguments from CMD. I've tested > this only on W2k. Point 2 looks hackish and dangerous to me.
I'd suggest create a small C wrapper to launch gitk. It would be much easier that way IMHO.
-- Duy
Johannes SixtRe: GIT on MinGW problem
Nguyen Thai Ngoc Duy wrote:
> I'd suggest create a small C wrapper to launch gitk. It would be much > easier that way IMHO.
Doh! You're right! It's even there already, right before our eyes:
pointy..clicky..pointy..clicky (aka: cp gitk git-k)
$ git k
:)
-- Hannes
Nguyen Thai Ngoc DuyRe: GIT on MinGW problem
On 5/29/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Nguyen Thai Ngoc Duy wrote: > > I'd suggest create a small C wrapper to launch gitk. It would be much > > easier that way IMHO. > > Doh! You're right! It's even there already, right before our eyes: > > pointy..clicky..pointy..clicky (aka: cp gitk git-k) > > $ git k > > :)
Maybe we should teach git.c to try gitk if git-k is not found ;)
> -- Hannes > >
-- Duy
Johannes Schindelin[PATCH] Make git-k an alias to gitk
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> ---
On Tue, 29 May 2007, Nguyen Thai Ngoc Duy wrote:
> On 5/29/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote: > > Nguyen Thai Ngoc Duy wrote: > > > I'd suggest create a small C wrapper to launch gitk. It > > > would be much easier that way IMHO. > > > > Doh! You're right! It's even there already, right before our > > eyes: > > > > pointy..clicky..pointy..clicky (aka: cp gitk git-k) > > > > $ git k > > > > :) > > Maybe we should teach git.c to try gitk if git-k is not found ;)
Something like this?
Makefile | 2 +- git.c | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile index 5f94630..01ab1ff 100644 --- a/Makefile +++ b/Makefile @@ -262,7 +262,7 @@ EXTRA_PROGRAMS = BUILT_INS = \ git-format-patch$X git-show$X git-whatchanged$X git-cherry$X \ git-get-tar-commit-id$X git-init$X git-repo-config$X \ - git-fsck-objects$X git-cherry-pick$X \ + git-fsck-objects$X git-cherry-pick$X git-k$X \ $(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS)) # what 'all' will build and 'install' will install, in gitexecdir diff --git a/git.c b/git.c index 04eb344..53d81e9 100644 --- a/git.c +++ b/git.c @@ -216,6 +216,11 @@ static int handle_alias(int *argcp, const char ***argv) return ret; } +static int cmd_gitk(int argc, const char **argv, const char *prefix) +{ + return execv("gitk", (char *const *)argv); +} + const char git_version_string[] = GIT_VERSION; #define RUN_SETUP (1<<0) @@ -274,6 +279,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp) { "help", cmd_help }, { "init", cmd_init_db }, { "init-db", cmd_init_db }, + { "k", cmd_gitk }, { "log", cmd_log, RUN_SETUP | USE_PAGER }, { "ls-files", cmd_ls_files, RUN_SETUP }, { "ls-tree", cmd_ls_tree, RUN_SETUP },
-- 1.5.2.2641.g404de-dirty
Johannes SixtRe: [PATCH] Make git-k an alias to gitk
Johannes Schindelin wrote:
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> On Tue, 29 May 2007, Nguyen Thai Ngoc Duy wrote:
>
> > On 5/29/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> > > pointy..clicky..pointy..clicky (aka: cp gitk git-k)
> > >
> > > $ git k
> > >
> > > :)
> >
> > Maybe we should teach git.c to try gitk if git-k is not found ;)
>
> Something like this?
>
> +static int cmd_gitk(int argc, const char **argv, const char *prefix)
> +{
> + return execv("gitk", (char *const *)argv);
> +}
> +This does not work. Windows's execv() does not know how to invoke shell (or tcl) scripts. Only execve() does, because we have our own implementation.
I'd prefer to install gitk under both names gitk and git-k (as hard links; which would amount to copies on Windows, but we don't care).
-- Hannes
Han-Wen NienhuysRe: GIT on MinGW problem
Johannes Sixt escreveu:
>> I'd suggest create a small C wrapper to launch gitk. It would be much >> easier that way IMHO. > > Doh! You're right! It's even there already, right before our eyes: > > pointy..clicky..pointy..clicky (aka: cp gitk git-k) > > $ git k > > :)
how about
git tk
that's more in line what actually happens. We can ship a gitk.bat that runs git-tk.
BTW, I got one report that gitk doesn't work with the tcl/tk that I ship. Can I have other reports too? ie.
"It doesn't work for me, I use windows 92" "It works for me, I use windows QZ"
etc.?
-- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
Johannes SchindelinRe: GIT on MinGW problem
Hi,
On Tue, 29 May 2007, Han-Wen Nienhuys wrote:
> Johannes Sixt escreveu: > >> I'd suggest create a small C wrapper to launch gitk. It would be much > >> easier that way IMHO. > > > > Doh! You're right! It's even there already, right before our eyes: > > > > pointy..clicky..pointy..clicky (aka: cp gitk git-k) > > > > $ git k > > > > :) > > how about > > git tk > > that's more in line what actually happens. We can ship a gitk.bat > that runs git-tk. > > BTW, I got one report that gitk doesn't work with the tcl/tk that I > ship. Can I have other reports too? ie. > > "It doesn't work for me, I use windows 92"
It worked for me, using Windows XP. (But I don't remember if I had to do some adjustments for it, or only for git-gui.)
BTW Almost any operation I run in git-gui fails, because cat is not found.
Ciao, Dscho
Shawn O. PearceRe: GIT on MinGW problem
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > BTW Almost any operation I run in git-gui fails, because cat is > not found.
That's the stuff that goes into a console and dumps both to stdout and stderr. E.g. fetch, push, "compress database".
The issue is Tcl doesn't give me a way to get a pipe to both stdout and stderr. I cannot get two pipes, nor can I get a single pipe with both stdout+stderr redirected to that pipe. Unless I pipe it into another process. Enter `cat`.
Would we consider a "--stderr-to-stdout" long option to git itself? Then I could have git-gui do:
git --stderr-to-stdout fetch
and bypass the pipe into cat. Yes, I know, its crap. Welcome to Tcl.
-- Shawn.
Johannes Schindelin[PATCH] Git wrapper: add --redirect-stderr option
With this option, stderr is redirected to stdout. The short option is '-2'.
Alternatively, you can say '--redirect-stderr=<filename>' to redirect stderr to a file.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> ---
On Tue, 29 May 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > > BTW Almost any operation I run in git-gui fails, because cat > > is not found. > > That's the stuff that goes into a console and dumps both to > stdout and stderr. E.g. fetch, push, "compress database". > > The issue is Tcl doesn't give me a way to get a pipe to both > stdout and stderr. I cannot get two pipes, nor can I get a > single pipe with both stdout+stderr redirected to that pipe. > Unless I pipe it into another process. Enter `cat`. > > Would we consider a "--stderr-to-stdout" long option to git > itself? Then I could have git-gui do: > > git --stderr-to-stdout fetch > > and bypass the pipe into cat. Yes, I know, its crap. Welcome > to Tcl.
How about this?
git.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c index 53d81e9..72e0539 100644 --- a/git.c +++ b/git.c @@ -82,6 +82,20 @@ static int handle_options(const char*** argv, int* argc) } else if (!strcmp(cmd, "--bare")) { static char git_dir[PATH_MAX+1]; setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 1); + } else if (!strcmp(cmd, "-2") || + !strcmp(cmd, "--redirect-stderr")) { + if (dup2(1, 2) < 0) + return error("Could not redirect stderr: %s", + strerror(errno)); + } else if (!prefixcmp(cmd, "--redirect-stderr=")) { + int fd = open(cmd + 18, O_WRONLY | O_CREAT, 0777), ret; + if (fd < 0) + return error("Could not open %s", cmd + 18); + ret = dup2(fd, 2); + close(fd); + if (ret < 0) + return error("Could not redirect stderr: %s", + strerror(errno)); } else { fprintf(stderr, "Unknown option: %s\n", cmd); usage(git_usage_string);
-- 1.5.2.2642.gc8bae-dirty
Shawn O. PearceRe: [PATCH] Git wrapper: add --redirect-stderr option
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > With this option, stderr is redirected to stdout. The short option is '-2'. > > Alternatively, you can say '--redirect-stderr=<filename>' to redirect > stderr to a file.
Yes, that works nicely. ;-)
Now here's my other problem: How does git-gui know the underlying git will accept --redirect-stderr? Or that it supports any other recent features we've developed?
Sure I can check the version, but until I know what version of Git its shipping in I cannot put the check into git-gui.
I was thinking about adding a "git-supported-features" plumbing command that prints back feature code strings, much as our network protocol supplies back the few feature codes it supports ("multi-ack", "sideband", etc.). E.g.:
$ git supported-features redirect-stderr ...
That way higher level Porcelain can poll the plumbing to see what is available, and what isn't.
-- Shawn.
Johannes SchindelinRe: [PATCH] Git wrapper: add --redirect-stderr option
Hi,
On Tue, 29 May 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > > With this option, stderr is redirected to stdout. The short option is '-2'. > > > > Alternatively, you can say '--redirect-stderr=<filename>' to redirect > > stderr to a file. > > Yes, that works nicely. ;-) > > Now here's my other problem: How does git-gui know the underlying > git will accept --redirect-stderr? Or that it supports any other > recent features we've developed?
I thought that git-gui is now really closely coupled with core-git.
> Sure I can check the version, but until I know what version of Git
> its shipping in I cannot put the check into git-gui.
>
> I was thinking about adding a "git-supported-features" plumbing
> command that prints back feature code strings, much as our
> network protocol supplies back the few feature codes it supports
> ("multi-ack", "sideband", etc.).Problem is: it would be more interesting to have this program in _older_ versions... ;-)
Ciao, Dscho
Shawn O. PearceRe: [PATCH] Git wrapper: add --redirect-stderr option
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Tue, 29 May 2007, Shawn O. Pearce wrote: > > > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > > > > With this option, stderr is redirected to stdout. The short option is '-2'. > > > > > > Alternatively, you can say '--redirect-stderr=<filename>' to redirect > > > stderr to a file. > > > > Yes, that works nicely. ;-) > > > > Now here's my other problem: How does git-gui know the underlying > > git will accept --redirect-stderr? Or that it supports any other > > recent features we've developed? > > I thought that git-gui is now really closely coupled with core-git.
Not really. It requires 1.5.0 and later, but after that it should be OK with any 1.5.x version of Git. Junio graciously bundles it with core Git, to help it get a wider audience. ;-)
However I'd like to let it be smarter about what it expects from the underling core Git. I'm sure the other Porcelain authors would also like to be able to determine if they can rely on something, or not. At the least we can just tell the user "Your Git old. Upgrade to new Git today!". Yes, bad Engrish included... ;-)
> > Sure I can check the version, but until I know what version of Git
> > its shipping in I cannot put the check into git-gui.
> >
> > I was thinking about adding a "git-supported-features" plumbing
> > command that prints back feature code strings, much as our
> > network protocol supplies back the few feature codes it supports
> > ("multi-ack", "sideband", etc.).
>
> Problem is: it would be more interesting to have this program in _older_
> versions... ;-)Lack of git-supported-features means only features before it coming into existance? ;-)
-- Shawn.
Johannes SchindelinRe: [PATCH] Git wrapper: add --redirect-stderr option
Hi,
On Tue, 29 May 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > > On Tue, 29 May 2007, Shawn O. Pearce wrote: > > > > > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > > > > > > With this option, stderr is redirected to stdout. The short option is '-2'. > > > > > > > > Alternatively, you can say '--redirect-stderr=<filename>' to redirect > > > > stderr to a file. > > > > > > Yes, that works nicely. ;-) > > > > > > Now here's my other problem: How does git-gui know the underlying > > > git will accept --redirect-stderr? Or that it supports any other > > > recent features we've developed? > > > > I thought that git-gui is now really closely coupled with core-git. > > Not really. It requires 1.5.0 and later, but after that it should > be OK with any 1.5.x version of Git. Junio graciously bundles it > with core Git, to help it get a wider audience. ;-) > > However I'd like to let it be smarter about what it expects from the > underling core Git. I'm sure the other Porcelain authors would also > like to be able to determine if they can rely on something, or not. > At the least we can just tell the user "Your Git old. Upgrade to new > Git today!". Yes, bad Engrish included... ;-)
When in doubt, you can always test the return value to check if the command line option is accepted...
Ciao, Dscho
Johannes SchindelinRe: GIT on MinGW problem
Hi,
On Sun, 27 May 2007, Han-Wen Nienhuys wrote:
> there is a > > bin/msys-1.0.dll > bin/libW11.dll > > inside the tarball. I want to know what they are, and how to build them.
Oops. I missed that. I guess that msys-1.0.dll is built from
http://downloads.sourceforge.net/mingw/msys-1.0.10-src.tar.bz2
and that libW11.dll is built from some package in
http://sourceforge.net/project/showfiles.php?group_id=37352
Ciao, Dscho