1. 05 Mar, 2013 1 commit
    • Kirill Smelkov's avatar
      Fix `make install` when configured with autoconf · b4eead95
      Kirill Smelkov authored
      Commit d8cf908c (config.mak.in: remove unused definitions) removed
      
          exec_prefix = @exec_prefix@
      
      from config.mak.in, because nobody directly used ${exec_prefix}, but
      overlooked that other autoconf definitions could indirectly expand that
      variable.
      
      For example the following snippet from config.mak.in
      
          prefix = @prefix@
          bindir = @bindir@
          gitexecdir = @libexecdir@/git-core
          datarootdir = @datarootdir@
          template_dir = @datadir@/git-core/templates
          sysconfdir = @sysconfdir@
      
      is expanded to
      
          prefix = /home/kirr/local/git
          bindir = ${exec_prefix}/bin                             <-- HERE
          gitexecdir = ${exec_prefix}/libexec/git-core            <--
          datarootdir = ${prefix}/share
          template_dir = ${datarootdir}/git-core/templates
          sysconfdir = ${prefix}/etc
      
      on my system, after `configure --prefix=$HOME/local/git`
      
      and withot exec_prefix being defined there I get an error on
      install:
      
          install -d -m 755 '/bin'
          install -d -m 755 '/libexec/git-core'
          install: cannot create directory `/libexec': Permission denied
          Makefile:2292: recipe for target `install' failed
      
      Fix it.
      Signed-off-by: default avatarKirill Smelkov <kirr@mns.spb.ru>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      b4eead95
  2. 19 Feb, 2013 1 commit
    • Jiang Xin's avatar
      Bugfix: undefined htmldir in config.mak.autogen · 55d9bf0a
      Jiang Xin authored
      Html documents will be installed to root dir (/) no matter what prefix
      is set, if run these commands before `make` and `make install-html`:
      
          $ make configure
          $ ./configure --prefix=<PREFIX>
      
      After the installation, all the html documents will copy to rootdir (/),
      and:
      
          $ git --html-path
          <PREFIX>
      
          $ git help -w something
          fatal: '<PREFIX>': not a documentation directory.
      
      This is because the variable "htmldir" points to a undefined variable
      "$(docdir)" in file "config.mak.autogen", which is generated by running
      `./configure`. By default $(docdir) generated by configure is supposed
      be set this way:
      
              datarootdir='${prefix}/share'
              htmldir='${docdir}'
              docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
      
      but since fc1c5415 (Honor configure's htmldir switch, 2013-02-02),
      we only set and export htmldir without doing so for PACKAGE_TARNAME
      (which is set to 'git' by the configure script).
      
      Add the required two variables "PACKAGE_TARNAME" and "docdir" to file
      "config.mak.in" will work this issue around.
      Signed-off-by: Jiang Xin's avatarJiang Xin <worldhello.net@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      55d9bf0a
  3. 04 Feb, 2013 1 commit
    • Junio C Hamano's avatar
      config.mak.in: remove unused definitions · d8cf908c
      Junio C Hamano authored
      When 55667714 (autoconf: Use autoconf to write installation
      directories to config.mak.autogen, 2006-07-03) introduced support
      for autoconf generated config.mak file, it added an "export" for a
      few common makefile variables, in addition to definitions of srcdir
      and VPATH.
      
      The "export" logically does not belong there.  The make variables
      like mandir, prefix, etc, should be exported to submakes for people
      who use config.mak and people who use config.mak.autogen the same
      way; if we want to get these exported, that should be in the main
      Makefile.
      
      We do use mandir and htmldir in Documentation/Makefile, so let's
      add export for them in the main Makefile instead.
      
      We may eventually want to support VPATH, and srcdir may turn out to
      be useful for that purpose, but right now nobody uses it, so it is
      useless to define them in this file.
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      d8cf908c
  4. 03 Feb, 2013 1 commit
  5. 10 Dec, 2012 1 commit
  6. 11 Sep, 2012 1 commit
    • Stefano Lattarini's avatar
      build: don't duplicate substitution of make variables · 40bfbde9
      Stefano Lattarini authored
      Thanks to our 'GIT_CONF_SUBST' layer in configure.ac, a make variable 'VAR'
      can be defined to a value 'VAL' at ./configure runtime in our build system
      simply by using "GIT_CONF_SUBST([VAR], [VAL])" in configure.ac, rather than
      having both to call "AC_SUBST([VAR], [VAL])" in configure.ac and adding the
      'VAR = @var@' definition in config.mak.in.  Less duplication, less margin
      for error, less possibility of confusion.
      
      While at it, fix some formatting issues in configure.ac that unnecessarily
      obscured the code flow.
      Signed-off-by: default avatarStefano Lattarini <stefano.lattarini@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      40bfbde9
  7. 30 May, 2012 1 commit
    • Jeff King's avatar
      docs: drop asciidoc7compatible flag · bf171262
      Jeff King authored
      When we made the switch to supporting asciidoc 8 in 4c7100a9
      (Documentation: adjust to AsciiDoc 8, 2007-06-14), we were
      able to leave most of the documentation intact by defining
      asciidoc7compatible.
      
      Since commit 6cf378f0 (docs: stop using asciidoc no-inline-literal,
      2012-04-26), we don't support versions of asciidoc older
      than 8.4.1, which is when inline literals were introduced.
      Therefore there is not much point in keeping our
      documentation compatible with asciidoc 7.
      
      So we are now free to drop the asciidoc7compatible flag and
      update the documentation itself to assume asciidoc8.
      Fortunately, doing the latter is very easy; we weren't using
      any of the constructs impacted by asciidoc7compatible, so
      there are no changes to make.
      
      The reason is somewhat subtle. The asciidoc7compatible
      affects only super/sub-scripts ("^" and "~") and index
      terms. We don't use the latter at all. Nor we do we use the
      former, but we did have to protect them from accidental
      expansion in constructs like "rev^1". However, all of our
      uses of "~" and "^" are either in code blocks (which are
      rendered literally), or inside backticks. Prior to 6cf378f0,
      backticks were not inline literals, and needed proper
      quoting. But post-6cf378f0, we don't have to worry whether we
      are using the old or new rules, as those characters are not
      interpreted at all in either case.
      
      I verified that the result of "make install-html
      install-man" is identical before and after this patch on
      asciidoc 8.6.7.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      bf171262
  8. 13 Feb, 2012 1 commit
  9. 06 Dec, 2011 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      i18n: add infrastructure for translating Git with gettext · 5e9637c6
      Ævar Arnfjörð Bjarmason authored
      Change the skeleton implementation of i18n in Git to one that can show
      localized strings to users for our C, Shell and Perl programs using
      either GNU libintl or the Solaris gettext implementation.
      
      This new internationalization support is enabled by default. If
      gettext isn't available, or if Git is compiled with
      NO_GETTEXT=YesPlease, Git falls back on its current behavior of
      showing interface messages in English. When using the autoconf script
      we'll auto-detect if the gettext libraries are installed and act
      appropriately.
      
      This change is somewhat large because as well as adding a C, Shell and
      Perl i18n interface we're adding a lot of tests for them, and for
      those tests to work we need a skeleton PO file to actually test
      translations. A minimal Icelandic translation is included for this
      purpose. Icelandic includes multi-byte characters which makes it easy
      to test various edge cases, and it's a language I happen to
      understand.
      
      The rest of the commit message goes into detail about various
      sub-parts of this commit.
      
      = Installation
      
      Gettext .mo files will be installed and looked for in the standard
      $(prefix)/share/locale path. GIT_TEXTDOMAINDIR can also be set to
      override that, but that's only intended to be used to test Git itself.
      
      = Perl
      
      Perl code that's to be localized should use the new Git::I18n
      module. It imports a __ function into the caller's package by default.
      
      Instead of using the high level Locale::TextDomain interface I've
      opted to use the low-level (equivalent to the C interface)
      Locale::Messages module, which Locale::TextDomain itself uses.
      
      Locale::TextDomain does a lot of redundant work we don't need, and
      some of it would potentially introduce bugs. It tries to set the
      $TEXTDOMAIN based on package of the caller, and has its own
      hardcoded paths where it'll search for messages.
      
      I found it easier just to completely avoid it rather than try to
      circumvent its behavior. In any case, this is an issue wholly
      internal Git::I18N. Its guts can be changed later if that's deemed
      necessary.
      
      See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
      a further elaboration on this topic.
      
      = Shell
      
      Shell code that's to be localized should use the git-sh-i18n
      library. It's basically just a wrapper for the system's gettext.sh.
      
      If gettext.sh isn't available we'll fall back on gettext(1) if it's
      available. The latter is available without the former on Solaris,
      which has its own non-GNU gettext implementation. We also need to
      emulate eval_gettext() there.
      
      If neither are present we'll use a dumb printf(1) fall-through
      wrapper.
      
      = About libcharset.h and langinfo.h
      
      We use libcharset to query the character set of the current locale if
      it's available. I.e. we'll use it instead of nl_langinfo if
      HAVE_LIBCHARSET_H is set.
      
      The GNU gettext manual recommends using langinfo.h's
      nl_langinfo(CODESET) to acquire the current character set, but on
      systems that have libcharset.h's locale_charset() using the latter is
      either saner, or the only option on those systems.
      
      GNU and Solaris have a nl_langinfo(CODESET), FreeBSD can use either,
      but MinGW and some others need to use libcharset.h's locale_charset()
      instead.
      
      =Credits
      
      This patch is based on work by Jeff Epler <jepler@unpythonic.net> who
      did the initial Makefile / C work, and a lot of comments from the Git
      mailing list, including Jonathan Nieder, Jakub Narebski, Johannes
      Sixt, Erik Faye-Lund, Peter Krefting, Junio C Hamano, Thomas Rast and
      others.
      
      [jc: squashed a small Makefile fix from Ramsay]
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarRamsay Jones <ramsay@ramsay1.demon.co.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      5e9637c6
  10. 27 May, 2011 1 commit
  11. 09 May, 2011 1 commit
  12. 17 Mar, 2011 1 commit
    • Jonathan Nieder's avatar
      unbreak and eliminate NO_C99_FORMAT · 28bd70d8
      Jonathan Nieder authored
      In the spirit of v1.5.0.2~21 (Check for PRIuMAX rather than
      NO_C99_FORMAT in fast-import.c, 2007-02-20), use PRIuMAX from
      git-compat-util.h on all platforms instead of C99-specific formats
      like %zu with dangerous fallbacks to %u or %lu.
      
      So now C99-challenged platforms can build git without provoking
      warnings or errors from printf, even if pointers do not have the same
      size as an int or long.
      
      The need for a fallback PRIuMAX is detected in git-compat-util.h with
      "#ifndef PRIuMAX".  So while at it, simplify the Makefile and configure
      script by eliminating the NO_C99_FORMAT knob altogether.
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      28bd70d8
  13. 24 Nov, 2010 1 commit
    • Jeff King's avatar
      docs: default to more modern toolset · 79c461d5
      Jeff King authored
      When the ASCIIDOC8 and ASCIIDOC_NO_ROFF knobs were built,
      many people were still on asciidoc 7 and using older
      versions of docbook-xsl. These days, even the almost
      2-year-old Debian stable needs these knobs turned.
      
      So let's turn them by default. The new knobs ASCIIDOC7 and
      ASCIIDOC_ROFF can be used to get the old behavior if people
      are on older systems.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      79c461d5
  14. 06 Oct, 2010 2 commits
    • Ævar Arnfjörð Bjarmason's avatar
      Makefile & configure: add a NO_FNMATCH_CASEFOLD flag · 4de066b6
      Ævar Arnfjörð Bjarmason authored
      On some platforms (like Solaris) there is a fnmatch, but it doesn't
      support the GNU FNM_CASEFOLD extension that's used by the
      jj/icase-directory series' fnmatch_icase wrapper.
      
      Change the Makefile so that it's now possible to set
      NO_FNMATCH_CASEFOLD=YesPlease on those systems, and add a configure
      probe for it.
      
      Unlike the NO_REGEX check we don't add AC_INCLUDES_DEFAULT to our
      headers. This is because on a GNU system the definition of
      FNM_CASEFOLD in fnmatch.h is guarded by:
      
          #if !defined _POSIX_C_SOURCE || _POSIX_C_SOURCE < 2 || defined _GNU_SOURCE
      
      One of the headers AC_INCLUDES_DEFAULT includes ends up defining one
      of those, so if we'd use it we'd always get
      NO_FNMATCH_CASEFOLD=YesPlease on GNU systems, even though they have
      FNM_CASEFOLD.
      
      When checking the flags we use:
      
          ifdef NO_FNMATCH
          ...
          else
          ifdef NO_FNMATCH_CASEFOLD
          ...
          endif
          endif
      
      The "else" so that we don't link against compat/fnmatch/fnmatch.o
      twice if both NO_FNMATCH and NO_FNMATCH_CASEFOLD are defined.
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4de066b6
    • Ævar Arnfjörð Bjarmason's avatar
      Makefile & configure: add a NO_FNMATCH flag · f3f3d936
      Ævar Arnfjörð Bjarmason authored
      Windows and MinGW both lack fnmatch() in their C library and needed
      compat/fnmatch, but they had duplicate code for adding the compat
      function, and there was no Makefile flag or configure check for
      fnmatch.
      
      Change the Makefile it so that it's now possible to compile the compat
      function with a NO_FNMATCH=YesPlease flag, and add a configure probe
      for it.
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      f3f3d936
  15. 19 Aug, 2010 1 commit
  16. 15 Aug, 2010 1 commit
  17. 01 Jun, 2010 4 commits
  18. 31 May, 2010 3 commits
  19. 15 Apr, 2010 1 commit
  20. 31 Jan, 2010 1 commit
  21. 23 Jul, 2009 1 commit
    • Brandon Casey's avatar
      configure.ac: rework/fix the NEEDS_RESOLV and NEEDS_LIBGEN tests · a1142892
      Brandon Casey authored
      The "action" parameters for these two tests were supplied incorrectly for
      the way the tests were implemented.  The tests check whether a program
      which calls hstrerror() or basename() successfully links when -lresolv or
      -lgen are used, respectively.  A successful linking would result in
      NEEDS_RESOLV or NEEDS_LIBGEN being unset, and failure would result in
      setting the respective variable.
      
      Aside from that issue, the tests did not handle the case where neither
      library was necessary for accessing the functions in question.  So solve
      both of these issues by re-working the two tests so that their form is like
      the NEEDS_SOCKET test which attempts to link with just the c library, and
      if it fails then assumes that the additional library is necessary and sets
      the appropriate variable.
      
      Also an entry in the config.mak.in file is necessary for the NEEDS_LIBGEN
      variable to appear in the config.mak.autogen file with the value assigned
      by the configure script.  Without it, the generated shell script would
      contain a snippet like this:
      
         for ac_lib in ; do
            ...
      
      which is incorrect.
      Signed-off-by: default avatarBrandon Casey <drafnel@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a1142892
  22. 10 Jun, 2009 1 commit
  23. 01 Jun, 2009 2 commits
  24. 05 Feb, 2009 1 commit
  25. 03 Dec, 2008 1 commit
  26. 02 Dec, 2008 1 commit
  27. 09 Nov, 2008 1 commit
  28. 02 Nov, 2008 1 commit
  29. 22 Aug, 2008 1 commit
  30. 18 Aug, 2008 1 commit
  31. 19 Jun, 2008 1 commit
  32. 11 Mar, 2008 1 commit
  33. 05 Mar, 2008 1 commit