{"thread":{"id":"32513","subject":"[RFH] NetBSD 6?","startedAt":"2013-01-02T23:11:50Z","lastAt":"2013-01-08T19:08:38Z","messageCount":11,"participants":["Junio C Hamano","Greg Troxel","Stefano Lattarini"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"205894","messageId":"7vd2xn18p5.fsf@alter.siamese.dyndns.org","threadId":"32513","inReplyTo":null,"subject":"[RFH] NetBSD 6?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-02T23:11:50Z","receivedAt":"2013-01-02T23:11:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I would appreciate if somebody with more familiarlity with the\nplatform can suggest a better alternative than applying the\nfollowing patch to our Makefile.  Right now I have an equivalent of\nthis change in config.mak locally when building on the said\nplatform.\n\nThe \"2.7\" bit certainly looks fishy, as users should be able to\nchoose between \"2.6\" and \"2.7\" (and possibly \"3.0\"), IIUC.\n\n Makefile | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/Makefile b/Makefile\nindex b0df41b..2ca6047 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1163,8 +1163,11 @@ ifeq ($(uname_S),NetBSD)\n \tifeq ($(shell expr \"$(uname_R)\" : '[01]\\.'),2)\n \t\tNEEDS_LIBICONV = YesPlease\n \tendif\n+\tPYTHON_PATH = /usr/pkg/bin/python2.7\n+\tPERL_PATH = /usr/pkg/bin/perl\n \tBASIC_CFLAGS += -I/usr/pkg/include\n \tBASIC_LDFLAGS += -L/usr/pkg/lib $(CC_LD_DYNPATH)/usr/pkg/lib\n+\tOLD_ICONV = YesPlease\n \tUSE_ST_TIMESPEC = YesPlease\n \tNO_MKSTEMPS = YesPlease\n \tHAVE_PATHS_H = YesPlease\n"},{"id":"205905","messageId":"rmiy5gbun7u.fsf@fnord.ir.bbn.com","threadId":"32513","inReplyTo":"7vd2xn18p5.fsf@alter.siamese.dyndns.org","subject":"Re: [RFH] NetBSD 6?","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2013-01-03T00:25:25Z","receivedAt":"2013-01-03T00:25:25Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nJunio C Hamano <gitster@pobox.com> writes:\n\n> [query about NetBSD-6] \n\n> The \"2.7\" bit certainly looks fishy, as users should be able to\n> choose between \"2.6\" and \"2.7\" (and possibly \"3.0\"), IIUC.\n>\n> +\tPYTHON_PATH = /usr/pkg/bin/python2.7\n> +\tPERL_PATH = /usr/pkg/bin/perl\n\n(I am one of the people who maintain the git package in pkgsrc.)\n\n(Strictly, this is not really about NetBSD, but about all systems where\nthe standard approach to get python is via pkgsrc.  So that include\nDragonflyBSD as well.  (pkgsrc runs on many other systems, but it isn't\nthe standard approach, so from the git viewpoint that's irrelevant.))\n\nYou are entirely right that on e.g. NetBSD 6 the view is that users\nshould be able to choose the python version.\n\npkgsrc can install multiple versions of python at the same time, to cope\nwith python-using packages that need different versions.  pkgsrc chooses\nnot to have a 'python' program, because that would result in installed\npackages changing their binding of which python version to use when the\ndefault was changed.  The default python version is currently 2.7, so\n/usr/pkg/bin/python2.7 is the best guess for finding python on a NetBSD\nsystem, if you're only allowed one guess.  A user can set a\nPYTHON_VERSION_DEFAULT variable to choose the version they want; each\npackage expresses which versions will work.\n\nThis isn't relevant for git, not being a pure python library, but pkgsrc\nsupports installing multiple versions of some packages, so one can have\ntwo versions installed at once:\n  py27-expat-0nb6     Python interface to expat\n  py26-expat-0nb6     Python interface to expat\nThe git package just depends on one version; by default the git package\ndepends on python (but one can tell it not to).\n\nThe python.m4 macro that comes with automake seems to find one of the\nvarious pythonX.Y binaries in $PATH just fine.\n\npkgsrc has an entry for git (at 1.8.0.1).\nThe key line for handling python is:\n  MAKE_FLAGS+=\tPYTHON_PATH=${PYTHONBIN}\nand there PYTHONBIN is set up by pkgsrc infrastructure for the right\nprefix (99.9% but not always /usr/pkg) and version.  After this,\neverything seems to come out right:\n\n  > head -1 /usr/pkg/libexec/git-core/git-p4\n  #!/usr/pkg/bin/python2.7\n\nSo I'd say that if PYTHON_PATH is set in the environment to configure,\nit should behave as it does now.  And if not, it would be nice if the\nhighest pythonX.Y found (that is known to work with git) is used.\n\n> +\tPYTHON_PATH = /usr/pkg/bin/python2.7\n> +\tPERL_PATH = /usr/pkg/bin/perl\n\nSo it would be nice to make these work as ?=, letting an environment\nvariable win if set.\n"},{"id":"205906","messageId":"rmipq1numzj.fsf@fnord.ir.bbn.com","threadId":"32513","inReplyTo":"7vd2xn18p5.fsf@alter.siamese.dyndns.org","subject":"Re: [RFH] NetBSD 6?","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2013-01-03T00:30:24Z","receivedAt":"2013-01-03T00:30:24Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nJunio C Hamano <gitster@pobox.com> writes:\n\n> I would appreciate if somebody with more familiarlity with the\n> platform can suggest a better alternative than applying the\n> following patch to our Makefile.  Right now I have an equivalent of\n> this change in config.mak locally when building on the said\n> platform.\n\nI realized after sending my previous reply that you are probably trying\nto have a way to build and run tests on NetBSD-6 from a git checkout as\npart of development testing.\n\nOne approach I've taken with other programs is to have a README.NetBSD\nfile which is actually an executable /bin/sh script with comments,\nexplaining the prereqs in terms of pkgsrc and invoking configure to get\ndependencies from pkgsrc (-I/usr/pkg/include plus -L/-R).\n\nSo in the git case, this could set PYTHON_PATH in the environment.\n\nI realize a README.foo file for N different systems could be clutter,\nbut having these checked in would provide the concise help that people\non any of those platforms need.\n"},{"id":"205908","messageId":"7vd2xnypt6.fsf@alter.siamese.dyndns.org","threadId":"32513","inReplyTo":"rmipq1numzj.fsf@fnord.ir.bbn.com","subject":"Re: [RFH] NetBSD 6?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-03T02:15:49Z","receivedAt":"2013-01-03T02:15:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg Troxel <gdt@ir.bbn.com> writes:\n\n> I realize a README.foo file for N different systems could be clutter,\n> but having these checked in would provide the concise help that people\n> on any of those platforms need.\n\nOur Makefile documents knobs people on various platforms can tweak\n(PYTHON_PATH and OLD_ICONV are two examples of them), sets default\nvalues for them based on $(uname -S), then includes config.mak file\nthe user can optionally create to override these platform defaults.\nThis infrastructure is used across platforms, not just for NetBSD.\n\nThe part shown in the patch was to update the platform default for\nNetBSD.  The setting we have been shipping in our Makefile seemed to\nbe different from what I needed on my NetBSD 6 install, and I was\nwondering if we have no real users of Git on the platorm (which\nwould explain why we didn't get any complaints or patches to update\nthis part).  Or there are some optional packages all real NetBSD\nusers install, but being a NetBSD newbie I didn't, that makes the\nvalues I showed in the patch inappropriate for them (e.g. Perhaps\nthere is a mechanism other than pkgsrc that installs perl and python\nunder /usr/bin?  Perhaps an optional libi18n package that gives\niconv(3) with new function signature?), in which case I definitely\nshould not apply that patch to my tree, as it would only be an\nimprovement for one person and a regression for existing users at\nthe same time.\n"},{"id":"205923","messageId":"rmi8v8av05d.fsf@fnord.ir.bbn.com","threadId":"32513","inReplyTo":"7vd2xnypt6.fsf@alter.siamese.dyndns.org","subject":"Re: [RFH] NetBSD 6?","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2013-01-03T13:58:22Z","receivedAt":"2013-01-03T13:58:22Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nJunio C Hamano <gitster@pobox.com> writes:\n\n> Greg Troxel <gdt@ir.bbn.com> writes:\n>\n>> I realize a README.foo file for N different systems could be clutter,\n>> but having these checked in would provide the concise help that people\n>> on any of those platforms need.\n>\n> Our Makefile documents knobs people on various platforms can tweak\n> (PYTHON_PATH and OLD_ICONV are two examples of them), sets default\n> values for them based on $(uname -S), then includes config.mak file\n> the user can optionally create to override these platform defaults.\n> This infrastructure is used across platforms, not just for NetBSD.\n\nIf you have to choose a single PYTHON_PATH, the one you picked is right\n(for now, and likely will be right for a long time).\n\nBut as a general rule, I think configure tests are preferable to\nOS-specific variables.\n\n> The part shown in the patch was to update the platform default for\n> NetBSD.  The setting we have been shipping in our Makefile seemed to\n> be different from what I needed on my NetBSD 6 install, and I was\n> wondering if we have no real users of Git on the platorm (which\n> would explain why we didn't get any complaints or patches to update\n> this part).  Or there are some optional packages all real NetBSD\n> users install, but being a NetBSD newbie I didn't, that makes the\n> values I showed in the patch inappropriate for them (e.g. Perhaps\n> there is a mechanism other than pkgsrc that installs perl and python\n> under /usr/bin?  Perhaps an optional libi18n package that gives\n> iconv(3) with new function signature?), in which case I definitely\n> should not apply that patch to my tree, as it would only be an\n> improvement for one person and a regression for existing users at\n> the same time.\n\nA large number of people on NetBSD use git, but almost all of them get\nit via pkgsrc (which is also where they get perl, emacs, svn, and\neverything else you didn't find in /usr/bin).  The exception would be\npeople that want to hack on git itself.\n\nPeople who want gnu libiconv can install the libiconv package from\npkgsrc.  (I'm guessing OLD_ICONV means \"POSIX iconv\", without GNU\nextensions (iconvctl?).)  The git package doesn't depend on GNU iconv,\nthough (perhaps it should but we tend to avoid dependencies that arren't\nreally needed).\n\nThere are no mechanisms to install python/perl in /usr/bin, and doing so\nwould be viewed as bizarre.  /usr/bin belongs to the base system,\n/usr/pkg to pkgsrc and /usr/local to the user.\n\nSo, it doesn't matter too much for pkgsrc what you change, because it\ncan be patched anyway (once, for all users).  It's probably better to\nmake a straightforward build from source come out right.\nBut, if the build respects the PYTHON_PATH environment variable, that's\neasier (and more robust against changes) than patching.\n"},{"id":"205936","messageId":"7vvcbew895.fsf@alter.siamese.dyndns.org","threadId":"32513","inReplyTo":"rmi8v8av05d.fsf@fnord.ir.bbn.com","subject":"Re: [RFH] NetBSD 6?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-03T16:17:58Z","receivedAt":"2013-01-03T16:17:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg Troxel <gdt@ir.bbn.com> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Greg Troxel <gdt@ir.bbn.com> writes:\n>>\n>>> I realize a README.foo file for N different systems could be clutter,\n>>> but having these checked in would provide the concise help that people\n>>> on any of those platforms need.\n>>\n>> Our Makefile documents knobs people on various platforms can tweak\n>> (PYTHON_PATH and OLD_ICONV are two examples of them), sets default\n>> values for them based on $(uname -S), then includes config.mak file\n>> the user can optionally create to override these platform defaults.\n>> This infrastructure is used across platforms, not just for NetBSD.\n>\n> If you have to choose a single PYTHON_PATH, the one you picked is right\n> (for now, and likely will be right for a long time).\n>\n> But as a general rule, I think configure tests are preferable to\n> OS-specific variables.\n\nI forgot to mention that we also ship configure (and keep track of\nconfigure.ac) so that optionally people can let autoconf machinery\nto create config.mak.autogen to be included at the same place as\nhandcrafted config.mak in their build process.  I do not offhand\nknow if we do \"for p in python python2.6 python2.7; do ...\" kind of\nthing, though.\n\n> A large number of people on NetBSD use git, but almost all of them get\n> it via pkgsrc (which is also where they get perl, emacs, svn, and\n> everything else you didn't find in /usr/bin).  The exception would be\n> people that want to hack on git itself.\n\nYeah, that much I figured ;-)\n\n> People who want gnu libiconv can install the libiconv package from\n> pkgsrc.  (I'm guessing OLD_ICONV means \"POSIX iconv\", without GNU\n> extensions (iconvctl?).)\n\nIt refers to the type of the second parameter to iconv(); OLD_ICONV\nmakes it take \"const char *\", as opposed to \"char *\", the latter of\nwhich matches\n\n  http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html\n\n> So, it doesn't matter too much for pkgsrc what you change, because it\n> can be patched anyway (once, for all users).\n\nYes.  The values in the Makefile are fallback defaults, and matters\nonly to people who build from the source.\n"},{"id":"205940","messageId":"rmiobh6rujt.fsf@fnord.ir.bbn.com","threadId":"32513","inReplyTo":"7vvcbew895.fsf@alter.siamese.dyndns.org","subject":"Re: [RFH] NetBSD 6?","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2013-01-03T18:27:34Z","receivedAt":"2013-01-03T18:27:34Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nJunio C Hamano <gitster@pobox.com> writes:\n\n> I forgot to mention that we also ship configure (and keep track of\n> configure.ac) so that optionally people can let autoconf machinery\n> to create config.mak.autogen to be included at the same place as\n> handcrafted config.mak in their build process.  I do not offhand\n> know if we do \"for p in python python2.6 python2.7; do ...\" kind of\n> thing, though.\n\npkgsrc uses the configure method, but it seems not to output a\nPYTHON_PATH.  It looks like automake's python.m4 is not used by git's\nconfigure.ac.  But pkgsrc passes PYTHON_PATH in the environment to make,\nso it works out currently.\n\n> It refers to the type of the second parameter to iconv(); OLD_ICONV\n> makes it take \"const char *\", as opposed to \"char *\", the latter of\n> which matches\n>\n>   http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html\n\nThanks - I now see our extra const and am looking into it.\n"},{"id":"205945","messageId":"50E5DBEB.9080009@gmail.com","threadId":"32513","inReplyTo":"rmiobh6rujt.fsf@fnord.ir.bbn.com","subject":"Re: [RFH] NetBSD 6?","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2013-01-03T19:28:43Z","receivedAt":"2013-01-03T19:28:43Z","isPatch":false,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"On 01/03/2013 07:27 PM, Greg Troxel wrote:\n> \n> Junio C Hamano <gitster@pobox.com> writes:\n> \n>> I forgot to mention that we also ship configure (and keep track of\n>> configure.ac) so that optionally people can let autoconf machinery\n>> to create config.mak.autogen to be included at the same place as\n>> handcrafted config.mak in their build process.  I do not offhand\n>> know if we do \"for p in python python2.6 python2.7; do ...\" kind of\n>> thing, though.\n> \n> pkgsrc uses the configure method, but it seems not to output a\n> PYTHON_PATH.  It looks like automake's python.m4 is not used by git's\n> configure.ac.\n>\nThat is not surprising, since Git build system doesn't use Automake :-)\n\nIn addition, it's worth nothing that Automake's python support (both\nin its m4 and make components) is intended as an help to install python\n*modules* from Autotools-based packages; using it for mere stand-alone\nscripts would be overkill.\n\nIn the case of Git, an adapted version of something like this might\nbe enough:\n\n  AC_CHECK_PROGS([PYTHON], [python python2.7 python2.6 python2.5])\n  if test -z \"$PYTHON\"; then\n    AC_MSG_WARNING([python not found])\n  fi\n\n  $PYTHON -c 'check-not-py3k' || AC_MSG_WARNING([Python 3 is not supported])\n  $PYTHON -c 'check-its-version' || AC_MSG_WARNING([python is too old])\n\n(Automake itself uses, in its own build system, a similar idiom to\nlook for a Perl interpreter at configure runtime).\n\nNot my itch so far, but I will happily review a patch if anyone is\nwilling to write it.\n\n> But pkgsrc passes PYTHON_PATH in the environment to make,\n> so it works out currently.\n> \n>> It refers to the type of the second parameter to iconv(); OLD_ICONV\n>> makes it take \"const char *\", as opposed to \"char *\", the latter of\n>> which matches\n>>\n>>   http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html\n> \n> Thanks - I now see our extra const and am looking into it.\n\nRegards,\n  Stefano\n"},{"id":"206323","messageId":"rmiobgz4icr.fsf@fnord.ir.bbn.com","threadId":"32513","inReplyTo":"7vvcbew895.fsf@alter.siamese.dyndns.org","subject":"Re: [RFH] NetBSD 6?","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2013-01-08T18:53:08Z","receivedAt":"2013-01-08T18:53:08Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nJunio C Hamano <gitster@pobox.com> writes:\n\n>>  [OLD_ICONV]\n\n> It refers to the type of the second parameter to iconv(); OLD_ICONV\n> makes it take \"const char *\", as opposed to \"char *\", the latter of\n> which matches\n>\n>   http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html\n\nI just wanted to follow up on this.  It turns out that the old POSIX\nstandard was buggy (header file and function spec were different), and\nthey resolved it in favor of non-const.  NetBSD followed the const way,\nand just now documented that with links to the standards email archives.\n\nInterestingly, GNU iconv 1.14 seems to define it as const also:\n\n  https://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1.14/iconv.3.html\n\n(which matches man/iconv.3 in the tarball).\n\nWhen I build libiconv-1.14, it produces a .h with const.  But it has a\nconfigure test to check if there is a host include file with const, and\nputs the const in the built header file or not to match!\nIn include/iconv.h.in, there is:\n\n  extern size_t iconv (iconv_t cd,\n      @ICONV_CONST@ char* * inbuf, size_t *inbytesleft,\n       char* * outbuf, size_t *outbytesleft);\n\nSomeday, it would be nice to have the configure test not fail an iconv\nimplementation just because of the const, unless the presence of const\nis causing a real problem.  But I can understand that no one thinks\nthat's important enough to get around to.\n\n\n"},{"id":"206325","messageId":"7vy5g3cx9v.fsf@alter.siamese.dyndns.org","threadId":"32513","inReplyTo":"rmiobgz4icr.fsf@fnord.ir.bbn.com","subject":"Re: [RFH] NetBSD 6?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-08T19:03:40Z","receivedAt":"2013-01-08T19:03:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg Troxel <gdt@ir.bbn.com> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>>>  [OLD_ICONV]\n>\n>> It refers to the type of the second parameter to iconv(); OLD_ICONV\n>> makes it take \"const char *\", as opposed to \"char *\", the latter of\n>> which matches\n>>\n>>   http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html\n>\n> I just wanted to follow up on this.  It turns out that the old POSIX\n> standard was buggy (header file and function spec were different), and\n> they resolved it in favor of non-const.  NetBSD followed the const way,\n> and just now documented that with links to the standards email archives.\n>\n> Interestingly, GNU iconv 1.14 seems to define it as const also:\n>\n>   https://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1.14/iconv.3.html\n>\n> (which matches man/iconv.3 in the tarball).\n>\n> When I build libiconv-1.14, it produces a .h with const.  But it has a\n> configure test to check if there is a host include file with const, and\n> puts the const in the built header file or not to match!\n> In include/iconv.h.in, there is:\n>\n>   extern size_t iconv (iconv_t cd,\n>       @ICONV_CONST@ char* * inbuf, size_t *inbytesleft,\n>        char* * outbuf, size_t *outbytesleft);\n>\n> Someday, it would be nice to have the configure test not fail an iconv\n> implementation just because of the const, unless the presence of const\n> is causing a real problem.  But I can understand that no one thinks\n> that's important enough to get around to.\n\nInteresting.\n\nDon't get too offended by the \"OLD_\" prefix to that symbol, by the\nway.  I do not think \"old\" means \"old and broken hence fixed in\nnewer version and you are low life if you live on a platform that\nhas to define it\" ;-).\n\nWe just needed to have a boolean to tell which variant it is to let\nthe compiler build objects without complaining, and we named that\nswitch as OLD_ICONV.\n"},{"id":"206326","messageId":"rmiip774hmx.fsf@fnord.ir.bbn.com","threadId":"32513","inReplyTo":"7vy5g3cx9v.fsf@alter.siamese.dyndns.org","subject":"Re: [RFH] NetBSD 6?","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2013-01-08T19:08:38Z","receivedAt":"2013-01-08T19:08:38Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\nJunio C Hamano <gitster@pobox.com> writes:\n\n> Don't get too offended by the \"OLD_\" prefix to that symbol, by the\n> way.  I do not think \"old\" means \"old and broken hence fixed in\n> newer version and you are low life if you live on a platform that\n> has to define it\" ;-).\n\nThanks - it did throw me at the beginning, because I expected that it\nlead to using a copy of GNU iconv and not using the native one.\nBut it will probably confuse few enough people that changing to\nCONST_ICONV is not warranted...\n\n> We just needed to have a boolean to tell which variant it is to let\n> the compiler build objects without complaining, and we named that\n> switch as OLD_ICONV.\n\nI get that, now that I read utf8.c.  It's amusing that git's own\nfunction is const, and on non-OLD_ICONV platforms has to cast away the\nconst for standards-compliant iconv.\n\n"}]}