aboutsummaryrefslogtreecommitdiff
path: root/perl/Makefile
Commit message (Collapse)AuthorAge
* Extract Git::SVN::GlobSpec from git-svn.Michael G. Schwern2012-07-27
| | | | | | | | Straight cut & paste. That's the last class. * Make Git::SVN load it on its own, its the only thing that needs it. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Move Git::IndexInfo into its own file.Michael G. Schwern2012-07-27
| | | | | | Straight cut & paste. Didn't require any fixing. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Extract Git::SVN::Migration from git-svn.Michael G. Schwern2012-07-27
| | | | | | Straight cut & paste. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Extract Git::SVN::Log from git-svn.Michael G. Schwern2012-07-27
| | | | | | | | Straight cut & paste. Also noticed Git::SVN::Ra wasn't in the compile test. It is now. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Extract Git::SVN from git-svn into its own .pm file.Michael G. Schwern2012-07-27
| | | | | | | | | | Except for adding the 1; at the end, this is a straight copy & paste. Tests still pass, but its doubtful Git::SVN will compile on its own without git-svn being loaded. Next commit will fix that. Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Extract some utilities from git-svn to allow extracting Git::SVN.Michael G. Schwern2012-07-27
| | | | | | | | | | | | | | | | Put them in a new module called Git::SVN::Utils. Yeah, not terribly original and it will be a dumping ground. But its better than having them in the main git-svn program. At least they can be documented and tested. * fatal() is used by many classes. * Change the $can_compress lexical into a function. This should be enough to extract Git::SVN. Signed-off-by: Michael G. Schwern <schwern@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* perl: detect new files in MakeMaker buildsJunio C Hamano2012-07-27
| | | | | | | | | | | While Makefile.PL now finds .pm files on its own, it does not detect new files after it generates perl/perl.mak. [ew: commit message, minor tweaks] ref: http://mid.gmane.org/7vlii51xz4.fsf@alter.siamese.dyndns.org Signed-off-by: Eric Wong <normalperson@yhbt.net>
* perl/Makefile: Fix a missing double-quoteJohannes Sixt2012-06-29
| | | | | | Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* perl/Makefile: move "mkdir -p" to module installation loop for maintainabilityJonathan Nieder2012-06-15
| | | | | | | | | | | | In the NO_PERL_MAKEMAKER=YesPlease fallback case, make the directory that will contain each module when installing it (simulating "install -D") instead of hardcoding "Git/SVN/Memoize is the deepest level". This should make this codepath which is not used often on development machines a little easier to maintain. Requested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* perl/Makefile: install Git::SVN::* when NO_PERL_MAKEMAKER=yes, tooJonathan Nieder2012-06-15
| | | | | | | | | | | | | | v1.7.11-rc1~12^2~2 (2012-05-27) and friends split some git-svn code into separate modules but did not update the fallback rules to install them when NO_PERL_MAKEMAKER is set. Add the appropriate rules so users without MakeMaker can use git-svn again. Affected modules: Git::SVN::Prompt, Git::SVN::Fetcher, Git::SVN::Editor, Git::SVN::Ra, Git::SVN::Memoize::YAML. Reported-by: Adam Roben <adam@roben.org> Signed-off-by: Jonathan Nieder <jrnieder@gmali.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* perl/Makefile: install Git::I18N under NO_PERL_MAKEMAKERÆvar Arnfjörð Bjarmason2012-03-16
| | | | | | | | | | | | | When I added the i18n infrastructure in v1.7.8-rc2-1-g5e9637c I forgot to install Git::I18N also when NO_PERL_MAKEMAKER=YesPlease was set. Change the generation of the fallback perl.mak file to do that. Now Git/I18N.pm is installed alongside Git.pm in such a way that anything that uses GITPERLLIB will find it. Reported-by: Tom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* i18n: add infrastructure for translating Git with gettextÆvar Arnfjörð Bjarmason2011-12-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <avarab@gmail.com> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* perl/Makefile: Unset INSTALL_BASE when making perl.makÆvar Arnfjörð Bjarmason2010-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | PREFIX and INSTALL_BASE are mutually exclusive. If both are supplied by INSTALL_BASE being set in PERL_MM_OPT ExtUtils::MakeMaker will produce an error: $ echo $PERL_MM_OPT INSTALL_BASE=/home/avar/perl5 $ make -C perl PERL_PATH='/usr/bin/perl' prefix='/home/avar' perl.mak make: Entering directory `/home/avar/g/git/perl' /usr/bin/perl Makefile.PL PREFIX='/home/avar' Only one of PREFIX or INSTALL_BASE can be given. Not both. make: *** [perl.mak] Error 255 make: Leaving directory `/home/avar/g/git/perl' Change the perl Makefile to work around this by explicitly unsetting INSTALL_BASE. INSTALL_BASE is set in PERL_MM_OPT by e.g. the popular local::lib package, from its documentation: eval $(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib 2>/dev/null) Many other environments might also have set PERL_MM_OPT before building Git. This change enables us to build in these environments. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pay attention to DESTDIR when building with NO_PERL_MAKEMAKERJunio C Hamano2009-09-22
| | | | | | | | | | | | | | | | Building with prefix=/some/where and temporarily installing it to elsewhere for tar'ing up is done with: make prefix=/some/where make prefix=/some/where DESTDIR=/else/where install Make handcrafted perl/perl.mak without NO_PERL_MAKEMAKER honour DESTDIR. Ancient ExtUtils::MakeMaker (pre 6.11?) has the same issue, but recent versions of Perl ships with at leat 6.17; this patch does not address that issue. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* perl/Makefile: handle paths with spaces in the NO_PERL_MAKEMAKER sectionBrandon Casey2008-08-06
| | | | | | | Use double quotes to protect against paths which may contain spaces. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* perl/Makefile: update NO_PERL_MAKEMAKER sectionBrandon Casey2008-07-25
| | | | | | | | The perl modules must be copied to blib/lib so they are available for testing. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* War on whitespaceJunio C Hamano2007-06-07
| | | | | | | | | This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Allow PERL_PATH="/usr/bin/env perl"Bryan Larsen2007-05-03
| | | | | | | | | | | | | There is a mechanism PERL_PATH in the Makefile to specify path to Perl binary, but sometimes it is convenient to let 'env' figure out where Perl comes from, with PERL_PATH="/usr/bin/env perl". Allowing this would make things easier to MacPorts, where we wish to work with the MacPorts perl if it is installed, but fall back to the system perl if it isn't. Signed-off-by: Bryan Larsen <bryan@larsen.st> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Do not output "GEN " when generating perl.makJohannes Schindelin2007-03-14
| | | | | | | | | | | This fixes the same issue as 8bef6204, which became an issue again after 31d0399c. Besides, it is not really helpful to print just "GEN " (_without_ "perl.mak"). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* More build output cleaning upAlex Riesen2007-03-06
| | | | | | | | | - print output file name for .c files - suppress output of the names of subdirectories when make changes into them - use GEN prefix for makefile generation in perl/ Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make 'make' quiet by defaultShawn O. Pearce2007-03-06
| | | | | | | | | Per Junio's suggestion we are setting 'make' to be quiet by default, with `make V=1` available to force GNU make back to its default behavior of showing each command it is running. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make 'make' quieter while building gitShawn O. Pearce2007-03-06
| | | | | | | | | | | | | | | | | | | | | | | | | I find it difficult to see compiler warnings amongst the massive spewing produced by GNU make as it works through our productions. This is especially true if CFLAGS winds up being rather long, due to a large number of -W options being enabled and due to a number of -D options being configured/required by my platform. By defining QUIET_MAKE (e.g. make QUIET_MAKE=YesPlease) during compilation users will get a less verbose output, such as: ... CC builtin-grep.c builtin-grep.c:187: warning: 'external_grep' defined but not used CC builtin-init-db.c CC builtin-log.c CC builtin-ls-files.c CC builtin-ls-tree.c ... The verbose (normal make) output is still the default. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix perl/ build.Junio C Hamano2006-12-08
| | | | | | | | | An earlier commit f848718a broke the build in perl/ directory by allowing the Makefile.PL to overwrite the now-tracked Makefile. Fix this by forcing Makefile.PL to produce its output in perl.mak as the broken commit originally intended. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make perl/ build procedure ActiveState friendly.Alex Riesen2006-12-04
On Cygwin + ActivateState Perl, Makefile generated with MakeMaker is not usable because of line-endings and back-slashes. This teaches perl/Makefile to write a handcrafted equivalent perl.mak file with 'make NO_PERL_MAKEMAKER=NoThanks'. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>