Junio C Hamano gits...@pobox.com writes:
[OLD_ICONV]
It refers to the type of the second parameter to iconv(); OLD_ICONV
makes it take const char *, as opposed to char *, the latter of
which matches
http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
I just wanted to
Greg Troxel g...@ir.bbn.com writes:
Junio C Hamano gits...@pobox.com writes:
[OLD_ICONV]
It refers to the type of the second parameter to iconv(); OLD_ICONV
makes it take const char *, as opposed to char *, the latter of
which matches
Junio C Hamano gits...@pobox.com writes:
Don't get too offended by the OLD_ prefix to that symbol, by the
way. I do not think old means old and broken hence fixed in
newer version and you are low life if you live on a platform that
has to define it ;-).
Thanks - it did throw me at the
Junio C Hamano gits...@pobox.com writes:
I forgot to mention that we also ship configure (and keep track of
configure.ac) so that optionally people can let autoconf machinery
to create config.mak.autogen to be included at the same place as
handcrafted config.mak in their build process. I do
Junio C Hamano gits...@pobox.com writes:
[query about NetBSD-6]
The 2.7 bit certainly looks fishy, as users should be able to
choose between 2.6 and 2.7 (and possibly 3.0), IIUC.
+ PYTHON_PATH = /usr/pkg/bin/python2.7
+ PERL_PATH = /usr/pkg/bin/perl
(I am one of the people who
Junio C Hamano gits...@pobox.com writes:
I would appreciate if somebody with more familiarlity with the
platform can suggest a better alternative than applying the
following patch to our Makefile. Right now I have an equivalent of
this change in config.mak locally when building on the said
Greg Troxel g...@ir.bbn.com writes:
I realize a README.foo file for N different systems could be clutter,
but having these checked in would provide the concise help that people
on any of those platforms need.
Our Makefile documents knobs people on various platforms can tweak
(PYTHON_PATH and
7 matches
Mail list logo
