Age | Commit message (Collapse) | Author | Files | Lines |
|
the perl installation will always create it and it's surprising when
it suddenly appears on your filesystem.
|
|
because some Perl modules make some (bad) assumptions about the
structure of a MakeMaker-generated Makefile. Instead, remove the
perllocal.pod file whenever a p5-* module or perl itself is removed.
While here, rename some of the install/deinstall templates to more
descriptive names.
Bump the PKGREVISION to 3.
|
|
$(prefix) == $(siteprefix) == $(vendorprefix)
so that if a perl module is configured with "perl Makefile.PL PREFIX=...",
then that single PREFIX definition will override all three of the
above, and files will be properly installed into the correct relative
path. Also, patch a test so that it understands the different behavior
of the pkgsrc ExtUtils::MakeMaker module. Bump the PKGREVISION to 2.
|
|
for INSTALLSITESCRIPT and INSTALLVENDORSCRIPT in MakeMaker-generated
Makefiles. Bump the PKGREVISION to 1.
|
|
|
|
for many "core" modules, UTF-8 and Unicode bugfixes, and ithreads
bugfixes.
The major changes are in the pkgsrc infrastructure to handle Perl and
Perl modules. All pkgsrc-installed Perl modules are now installed in
"vendor" directories, and the perl interpreter has been modifed to
search for libraries in the following order: site, vendor, perl. The
Perl library is stored in a directory that is named for the Perl ABI
version associated with the Perl release, so any updates of Perl to
newer versions can be done "in-place" as long as Perl ABI version
remains the same. All Perl scripts and man pages are stored in
locations that won't conflict between site, vendor, and perl modules,
and a new utility perllink(1) now manages symlinks to those scripts
and man pages under the usual ${LOCALBASE}/bin and ${LOCALBASE}/man/man1.
PERL5_SITEPREFIX may be set to the prefix where local, site-specific
modules will be installed, e.g. PERL5_SITEPREFIX=/usr/local. Note
that modules installed here are completely unmanaged by pkgsrc.
Update the buildlink and tool dependencies on perl to require perl>=5.8.7
to reflect the new locations for Perl modules and the Perl shared
library.
|
|
around at either build-time or at run-time is:
USE_TOOLS+= perl # build-time
USE_TOOLS+= perl:run # run-time
Also remove some places where perl5/buildlink3.mk was being included
by a package Makefile, but all that the package wanted was the Perl
executable.
|
|
run-time dependency (DEPENDS) on a tool is to append a ":run" modifier
to the tool name, e.g.,
USE_TOOLS+= perl:run
Tools without modifiers or with an explicit ":build" modifier will
cause build dependencies (BUILD_DEPENDS) on those tools to be added.
This makes the notation a bit more compact.
|
|
These paths are now relative to PERL5_PACKLIST_DIR, which currently
defaults to ${PERL5_SITEARCH}. There is no change to the binary
packages.
|
|
|
|
been committed with the previous change. Noted by jlam@.
Bump PKGREVISION.
|
|
Config.pm. Bump PKGREVISION.
|
|
lang/perl5 to perl-5.8.6nb4. Modify packages that referred to
lang/perl58 to point to lang/perl5 instead.
|
|
|
|
goes away by itself.
|
|
|
|
|
|
perl5/module.mk into tools/perl.mk so that the substitution occurs for
all packages that use perl.
|
|
probably has something to do with how make deals with short-circuit
evaluation of conditionals, but it's a simple matter to split the
conditional since USE_PERL5 is eventually going away.
|
|
framework will handle adding the correct dependency.
|
|
Plan:
(1) Change USE_PERL5=build into USE_TOOLS+=perl.
(2) Change all other USE_PERL5 into including perl5/buildlink3.mk.
Possibly, for packages that don't actually build anything with perl,
but merely require it for the perl interpreter, we can instead do:
USE_TOOLS+= perl
TOOLS_DEPMETHOD.perl= DEPENDS
but this is more verbose than simply including the perl5/buildlink3.mk
file.
Move the PERL5_REQD computation into a lang/perl5/version.mk file,
and only do the USE_PERL5 logic in bsd.pkg.use.mk if we're not using
the new tools framework. This consolidates all of the perl-handling
into two places -- lang/perl5 and mk/tools/perl.mk.
|
|
using them, as these values are referenced till later when the variables
will definitely have the correct value. This removes the need to
include vars.mk here.
|
|
computation by caching the variables using MAKEVARS.
|
|
|
|
This fixes (at least) the build of mail/p5-razor-agents on NetBSD 1.6.2.
Ok'ed by jlam.
|
|
|
|
we don't want it to find. The usual buildlink techniques don't work
here since the Configure script uses a file existence test instead of
a linker test to see if the library exists. For each operating system
that we support in pkgsrc, there should be corresponding
LIBSWANTED.${OPSYS} and SYSLIBPATH.${OPSYS} definitions in the Perl
package Makefiles to ensure we only get what we ask for.
In this particular case, add the appropriate definitions for OpenBSD
so that we don't pick up random libraries that may also be installed
on the system.
|
|
Before, we were possibly using the values gleaned from a pre-existing
perl binary via perl5/vars.mk (pulled in by bsd.pkg.use.mk), which
would lead to the new perl using the pre-existing perl's version-specific
libraries. Bump the PKGREVISION of lang/perl5 to 11 and lang/perl58
to 4.
|
|
|
|
|
|
does. This allows us to use dynamic PLISTs for Perl modules that are
built using Module::Build. Bump the PKGREVISION of p5-Module-Build
to 1.
* Drop the use of PERL5_USES_MODULE_BUILD and introduce a new variable
PERL5_MODULE_TYPE that is either "MakeMaker" or "Module::Build" that
names the framework used to build/install the module.
* Split out the variables set in perl5/buildlink3.mk that are also used
by perl5/module.mk into a new file perl5/vars.mk. Move some PERL5_*
variable definitions from pkgsrc/mk/bsd.pkg.use.mk into perl5/vars.mk.
This just centralizes the common PERL5_* definitions into a single
file location.
* Convert the known packages that use Module::Build to set
PERL5_MODULE_TYPE and PERL5_PACKLIST:
devel/p5-Class-Container
devel/p5-Exception-Class
devel/p5-Log-Dispatch
devel/p5-Array-Compare
textproc/p5-Pod-Coverage
www/p5-Apache-Session-Wrapper
www/p5-MasonX-Request-WithApacheSession
|
|
|
|
for packages that want it.
|
|
perl58 for everything, and remove this package altogether.
|
|
PR pkg/28619. this should have been part of the PKGREVISION bump of p5-*.
|
|
module directory has changed (eg. "darwin-2level" vs.
"darwin-thread-multi-2level").
binary packages of perl modules need to be distinguishable between
being built against threaded perl and unthreaded perl, so bump the
PKGREVISION of all perl module packages and introduce
BUILDLINK_RECOMMENDED for perl as perl>=5.8.5nb5 so the correct
dependencies are registered and the binary packages are distinct.
addresses PR pkg/28619 from H. Todd Fujinaka.
|
|
installation needed when including perl5/buildlink3.mk. The only
option currently supported is "threads", which implies that a perl
that supports threads is required. The requirement is checked at
pre-install time using an INSTALL script template by both the package
build and the binary package.
Add PERL5_OPTIONS+=threads to both devel/p5-SDL and graphics/p5-GD
since those modules require a perl that supports threads.
|
|
|
|
|
|
handling has been moved into mk/compiler/mipspro.mk.
|
|
which are the full option names used to set rpath directives for the
linker and the compiler, respectively. In places were we are invoking
the linker, use "${LINKER_RPATH_FLAG} <path>", where the space is
inserted in case the flag is a word, e.g. -rpath. The default values
of *_RPATH_FLAG are set by the compiler/*.mk files, depending on the
compiler that you use. They may be overridden on a ${OPSYS}-specific
basis by setting _OPSYS_LINKER_RPATH_FLAG and _OPSYS_COMPILER_RPATH_FLAG,
respectively. Garbage-collect _OPSYS_RPATH_NAME and _COMPILER_LD_FLAG.
|
|
|
|
|
|
with GCC on AIX. Okayed by grant.
|
|
to fix the problems seen in the PLIST files.
|
|
the PERL defintionen in the Makefile resulting from Makefile.PL gets
set to 0 if LANG || LC_<something> is set to something else (read non english).
ok'd by jlam@
|
|
Georg Schwarz in PR pkg/25057:
- check for PKGSRC_COMPILER instead of USE_MIPSPRO:
USE_MIPSPRO would imply the former, but not the other way around.
That is, it's conceivable to have a system that has PKGSRC_COMPILER
set (to mipspro), but not USE_MIPSPRO.
- Allow passing of -Duse64bitint if ABI == 64 even if the compiler is not
mipspro. (Note: we could test this on a non-IRIX 64bit platform by
setting ABI to '64'. I think that should work, too, but I can't test
that right now.)
|
|
|
|
|
|
only set mipspro specific compiler flags when using mipspro.
Otherwise, defaults will do.
|