Commit graph

26 commits

Author SHA1 Message Date
joerg
bebc25606c Require xpkgwedge 1.15. 2006-01-12 19:05:06 +00:00
jlam
9acbdab507 Don't ever depend on xpkgwedge if we're building xpkgwedge. 2006-01-12 18:39:13 +00:00
rillig
999f8b6e04 Applied all quoting fixes found by "pkglint --autofix". 2005-12-05 22:07:07 +00:00
joerg
8ee73fae68 Add IMAKE_GAMEMAN_SUFFIX and IMAKE_GAMEMAN_DIR to allow PLISTs
to pick up the correct locations.

XXX Default values are guessed, x11/xsnow can be used for testing
2005-12-04 01:44:30 +00:00
tv
ff9bb60b8f Bump LIBTOOL_REQD to 1.5.18nb5. This pulls in the -avoid-version fix for
some platforms, which includes all non-ELFs and many ELF-like platforms
(that still use a.out naming conventions).

Since a branch is coming, bump the version in a blanket rather than per
platform.
2005-09-21 20:37:01 +00:00
jlam
40b99e5f80 Tools that are marked with ":pkgsrc" are needed very early on, probably
too early for pkgsrc to adequately cope.  In this case, imake-check.mk
was marking "imake" as a tool that was used to perform some tests.
This was causing xpkgwedge to be unnecessarily marked as a build
dependency since using imake in pkgsrc pretty much requires xpkgwedge.
However, in the case where we are running the "imake checks", we don't
need xpkgwedge around.

Solve this issue by marking all the tools in imake-check.mk with
":pkgsrc", and modify the xpkgwedge dependency test to not care about
"imake:pkgsrc".
2005-07-19 23:01:55 +00:00
jlam
6efbd72779 Clean up some clutter in pkgsrc/mk: move the ${OPSYS}.*.dist mtree
files into mk/platform, where they now live with the ${OPSYS}.mk files.
2005-06-23 18:41:57 +00:00
jlam
bdead8cfd3 Require xpkgwedge>=1.14 so that the correct make is always invoked on
Solaris and Linux, regardless of whether we use the same make to build
the software or not.
2005-06-14 20:14:50 +00:00
jlam
b3c6a77a03 We need xpkgwedge whenever we use imake. 2005-06-14 20:04:36 +00:00
jlam
33a4d9397c Require xpkgwedge>=1.13 when used as a build dependency so that the
correct make(1) program is invoked by pkgxmkmf.
2005-06-14 07:25:24 +00:00
jlam
baa963cd7c We only need to set USE_X11BASE, run install.man, and override the
compiler (CC/CXX) if we're actually using imake to generate Makefiles
for building and installing software.  This fixes errors in various
KDE-3.x packages that use imake for other purposes.
2005-06-14 02:09:38 +00:00
jlam
95fd1f6ec9 Massive cleanup of buildlink3.mk and builtin.mk files in pkgsrc.
Several changes are involved since they are all interrelated.  These
changes affect about 1000 files.

The first major change is rewriting bsd.builtin.mk as well as all of
the builtin.mk files to follow the new example in bsd.builtin.mk.
The loop to include all of the builtin.mk files needed by the package
is moved from bsd.builtin.mk and into bsd.buildlink3.mk.  bsd.builtin.mk
is now included by each of the individual builtin.mk files and provides
some common logic for all of the builtin.mk files.  Currently, this
includes the computation for whether the native or pkgsrc version of
the package is preferred.  This causes USE_BUILTIN.* to be correctly
set when one builtin.mk file includes another.

The second major change is teach the builtin.mk files to consider
files under ${LOCALBASE} to be from pkgsrc-controlled packages.  Most
of the builtin.mk files test for the presence of built-in software by
checking for the existence of certain files, e.g. <pthread.h>, and we
now assume that if that file is under ${LOCALBASE}, then it must be
from pkgsrc.  This modification is a nod toward LOCALBASE=/usr.  The
exceptions to this new check are the X11 distribution packages, which
are handled specially as noted below.

The third major change is providing builtin.mk and version.mk files
for each of the X11 distribution packages in pkgsrc.  The builtin.mk
file can detect whether the native X11 distribution is the same as
the one provided by pkgsrc, and the version.mk file computes the
version of the X11 distribution package, whether it's built-in or not.

The fourth major change is that the buildlink3.mk files for X11 packages
that install parts which are part of X11 distribution packages, e.g.
Xpm, Xcursor, etc., now use imake to query the X11 distribution for
whether the software is already provided by the X11 distribution.
This is more accurate than grepping for a symbol name in the imake
config files.  Using imake required sprinkling various builtin-imake.mk
helper files into pkgsrc directories.  These files are used as input
to imake since imake can't use stdin for that purpose.

The fifth major change is in how packages note that they use X11.
Instead of setting USE_X11, package Makefiles should now include
x11.buildlink3.mk instead.  This causes the X11 package buildlink3
and builtin logic to be executed at the correct place for buildlink3.mk
and builtin.mk files that previously set USE_X11, and fixes packages
that relied on buildlink3.mk files to implicitly note that X11 is
needed.  Package buildlink3.mk should also include x11.buildlink3.mk
when linking against the package libraries requires also linking
against the X11 libraries.  Where it was obvious, redundant inclusions
of x11.buildlink3.mk have been removed.
2005-06-01 18:02:37 +00:00
jlam
9f94b112f0 Remove the old tools framework and references to _USE_NEW_TOOLS. 2005-05-22 19:11:12 +00:00
jlam
d6f6120540 Goal: Remove USE_PERL5 from pkgsrc.
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.
2005-05-18 22:42:07 +00:00
tv
6dd847be9f Since there may have been merge errors in libtool-base 1.5.18, force
LIBTOOL_REQD to 1.5.18nb1.
2005-05-18 14:41:50 +00:00
jlam
3823422ca7 If USE_TOOLS has "perl" then also define PERL5_PKGSRCDIR for use by
mk/tools/perl.mk.  This fixes broken dependencies on perl where the
path to the package wasn't defined.
2005-05-17 22:49:55 +00:00
jlam
39cbd126b0 Make USE_TOOLS+=imake imply USE_X11BASE=yes, along with the other
variable definitions that apply when USE_IMAKE is defined.
2005-05-17 22:22:52 +00:00
jlam
1ee9760a81 Teach the new tools framework more about perl. We include perl5/vars.mk
in mk/tools/perl.mk since many packages expect to be able to use the
variables defined in vars.mk, but those variables can only be defined
if PERL5 is correctly defined, and that is only true after it is set
here.
2005-05-12 21:03:46 +00:00
jlam
69406c81f0 Don't check for whether variables are defined or not before adding
them to PLIST_SUBST.  They may simply be defined later on in the
Makefile processing.  Instead check whether USE_PERL5 was specified
to determine whether to pass along PERL5_{SITEARCH,SITELIB,ARCHLIB}
to PLIST_SUBST.
2005-05-12 20:31:56 +00:00
markd
45afaa0eca Sense of a USE_BUILDLINK3 test was reversed when USE_BUILDLINK3 was
switched on always, resulting in instances of X11R6/lib libraries being
linked in to binaries along with pkgsrc versions of the same. Fix.
2005-04-09 23:16:45 +00:00
tv
fe3c1321bf USE_BUILDLINK3 is no longer optional (and cannot be turned off). Per mail
to tech-pkg:

=====

* USE_BUILDLINK3=YES will be unconditional.  (In fact, USE_BUILDLINK3 will
  be ignored altogether by mk/; but see below.)

* NO_BUILDLINK and NO_WRAPPER will be ignored by mk/.  If a build happens,
  these phases will happen.

* The existing NO_BUILD will imply the previous NO_BUILDLINK and NO_WRAPPER.
  If no build happens, those phases are not needed.

* NO_TOOLS will be ignored by mk/.  The tools phase, which provides much
  more than just the C compiler, will always happen regardless of package.
  This will make metapackage builds only slightly slower, in trade for far
  less user error.
2005-03-24 17:46:00 +00:00
tv
6fba2a93ed Bump LIBTOOL_REQD to 1.5.14; this unifies all the support again and fixes
a good number of bugs.
2005-03-22 15:40:06 +00:00
jlam
cc44d0be98 * Teach devel/p5-Module-Build to write .packlists just like MakeMaker.pm
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
2005-02-24 22:38:41 +00:00
tv
4c2cccef33 Migrate the big block of USE_PERL5 and PERL5_REQD logic to bsd.pkg.use.mk. 2005-02-11 16:15:53 +00:00
tv
4b3f94acc8 Migrate several USE_* logic blocks, previously sprinkled liberally
throughout bsd.pkg.mk, to labelled blocks in bsd.pkg.use.mk.
2005-02-11 16:11:36 +00:00
tv
5655fbe984 Merge down some more visual cleanup from tv-derecurse to reduce divergence.
Part of this, introduce bsd.pkg.use.mk, where the Special Logic invoked
by various pkgsrc-wide USE_* variables will be migrated/consolidated.
2005-02-11 15:55:13 +00:00