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
platform.
The "2.7" bit certainly looks fishy,
Junio C Hamano 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 maint
Junio C Hamano 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
> platform.
I
Greg Troxel 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 OLD_ICONV are
Junio C Hamano writes:
> Greg Troxel 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 t
Greg Troxel writes:
> Junio C Hamano writes:
>
>> Greg Troxel 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 pe
Junio C Hamano 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 not offhand
>
On 01/03/2013 07:27 PM, Greg Troxel wrote:
>
> Junio C Hamano 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 c
Junio C Hamano 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 follow
Greg Troxel writes:
> Junio C Hamano 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
Junio C Hamano 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 beginning, b
11 matches
Mail list logo
