Commit graph

18 commits

Author SHA1 Message Date
wiz
e2718d1233 Remove support for obsolete and unused NO_DEPENDS. 2007-03-02 05:58:34 +00:00
rillig
10afa91e81 Since hooks must not have any commands directly assigned to them, it is
safe to remove the multiple-definition-guard.
2007-01-02 17:23:41 +00:00
jlam
7a2c97d53f * Add a new stage "bootstrap-depends" that happens before all other
stages, and that installs dependencies listed in BOOTSTRAP_DEPENDS.
  The bootstrap-depends step works just like the normal depends step
  and honors the value of DEPENDS_TARGET.  It's now possible to add
  dependencies solely to facilitate fetching the distfiles, e.g.

	BOOTSTRAP_DEPENDS+=	curl-[0-9]*:../../www/curl

* Teach the tools framework about ":bootstrap" as a tools modifier
  which indicates the tool should be added as a dependency via
  BOOTSTRAP_DEPENDS.

* Add "digest" to the tools framework.

* Use USE_TOOLS+=digest:bootstrap to force pkgsrc to install digest
  before anything else.  Get rid of unused "uptodate-digest" target
  and related digest version-checking code.

* Finish the refactoring work: split checksum-related code out of
  bsd.pkg.mk and into pkgsrc/mk/checksum and replace the "checksum"
  target command list with a script that does all the real work.

* Make DIGEST_ALGORITHMS and PATCH_DIGEST_ALGORITHM into private
  variables by prepending them with an underscore.  Also, rename
  _PATCH_DIGEST_ALGORITHM to _PATCH_DIGEST_ALGORITHMS and adjust the
  makepatchsum target to allow that variable to contain a list of
  algorithms, all of which are used when creating the patch checksums
  for ${DISTINFO_FILE}.
2006-07-13 14:02:34 +00:00
jlam
356f5e8af5 Rename <phase>_COOKIE variables to _COOKIE.<phase>. These are private
variables so there are no user-visible changes.  This change just makes
it a little easier to write for loops.
2006-07-07 21:24:27 +00:00
jlam
a8fcae3925 The cookie files are indirectly made using *-cookie targets, so verify
that they are never being created more than once by inserting a check
into the *-cookie targets.
2006-07-06 22:29:52 +00:00
jlam
b8d23232b8 Flatten out recursive makes into a single re-invocation of make by
introducing the concept of a "barrier".  We separate the user-invokable
targets into ones that must happen before the barrier, and ones that
must happen after the barrier.  The ones that happen after the barrier
are run in a sub-make process.  In this case, the targets that must
be run after the barrier are from the "wrapper" step and beyond.  We
rewrite the various "flow" targets, e.g. wrapper, configure, build,
etc., so that they of the right form to use the barrier target.

This now completely removes the concept of PKG_PHASE from pkgsrc.  It
is replaced with the concept of "before" and "after" the barrier, and
this state can be checked by testing for the existence of the barrier
cookie file.  Because we've removed most of the recursive makes, there
is now nowhere to hook the PKG_ERROR_HANDLER.* commands, so remove
them for now.

As part of this commit, put back the logic that conditionalized the
sources for the various cookie files.  Because the sources are all
"phony" targets, they were always run, regardless of whether or not
the cookie file already existed.  Now, if a cookie file exists, then
that entire phase associated with that cookie file is skipped.

Lastly, fix a thinko in configure/bsd.configure.mk where setting
NO_CONFIGURE in a package Makefile would manage to skip the "wrapper"
step altogether.  Fix this by correctly noting "wrapper" and not
"patch" as the preceding step to "configure".
2006-07-05 22:21:02 +00:00
jlam
990d0b5377 Make the check-vulnerable target more self-sufficient, by moving some
of the logic from fetch/fetch.mk into flavor/pkg/check.mk, so that
check-vulnerable can be used as a source target.

Make check-vulnerable a source target for every phase of the build
workflow, which ensures that it is always run if the user starts a
new phase from the command line.

Fix the cookie-generation targets so that they don't append, only
overwrite to the cookie file.  This works around potential problems
due to recursive makes.

Move the cookie checks so that they surround the corresponding phase
target.  The presence of the cookie should now inform the make process
to avoid doing any processing of phases that occur before the phase
corresponding to the cookie.
2006-07-05 09:08:35 +00:00
jlam
aa3aec191d _DEPENDS_COOKIE is already defined in bsd.depends-vars.mk. 2006-06-12 01:20:37 +00:00
jlam
8c10d39139 Introduce the capability to gather all the warnings and errors that
are generated for a target and output them all at once at the conclusion
of the target's invocation.  The implementation is in bsd.pkg.error.mk,
which defines a macro target "error-check" that will print out any
non-empty warning and error files in ${WARNING_DIR} and ${ERROR_DIR}
and exit appropriately if there were errors.

Convert some targets that were just long sequences of ${ERROR_MSG} or
${WARNING_MSG} within a single shell statement to use the new delayed
error output via error-check.

Modify the compiler "fail" wrappers for C++ and Fortran to be less
verbose during invocation.  Instead collect the warnings and only
print them at the end of the completed phase, e.g. after "configure"
and/or "build" completes.
2006-06-09 13:59:06 +00:00
jlam
6d0a3eea15 Make use of a "real-depends" helper target to hook all of the other
targets onto, and move the depends-message further down so that if
the depends cookie file already exists, then no message is outputted.
2006-06-08 15:45:06 +00:00
rillig
5fc064978a Since "depends" is a real pkgsrc phase now, it also needs its own
depends-message target.
2006-06-08 08:55:10 +00:00
jlam
dfed7426cb real-su-bin-install is no more... it's just su-bin-install. 2006-06-06 18:24:44 +00:00
jlam
3058ace76f Move some variable definitions out of bsd.prefs.mk and back into
bsd.pkg.mk.  They didn't actually need to be defined in bsd.prefs.mk,
just somewhere before the "main" bsd.<phase>.mk files were included.
This moves some conditional (?=) definitions back into bsd.pkg.mk so
they won't conflict with any conditional definitions in package
Makefiles.

This should fix the "checksum" problems in lang/php-gd as noted here:

    http://mail-index.netbsd.org/pkgsrc-users/2006/06/05/0012.html

where EXTRACT_SUFX had the wrong value due to the order in while *.mk
files were included.
2006-06-06 15:28:51 +00:00
jlam
e3f0f1869f Allow overrides of the public targets, e.g. "install", "package", etc.
if PKG_SKIP_REASON or PKG_FAIL_REASON is defined.  This commit adds
!target(...) guards around those target definitions to avoid "duplicate
target definition" warnings.
2006-06-05 17:41:11 +00:00
jlam
aa5856070f Move definitions for UPDATE_TARGET and DEPENDS_TARGET closer to where
they are used.  Also, move UPDATE_RUNNING into the install module where
it is used, and make it "private" by prepending with an underscore.
2006-06-05 17:21:54 +00:00
jlam
3b91a4e076 Revert previous, as the bug seems to have been fixed elsewhere. We will
revisit this if the problem crops up again.
2006-06-05 14:11:39 +00:00
seb
99640dd6b7 We really want to have the ${_DEPENDS_COOKIE} target to do something if it
has not been already defined not if the ${_DEPENDS_COOKIE} file does not exist.

This fix ${_DEPENDS_COOKIE} creation for me when doing 'make depends'.
2006-06-04 19:04:57 +00:00
jlam
e5eb2c56af First pass at implementing support for package system flavors other
than pkgsrc's current one.  This is an important lead-up to any project
that redesigns the pkg_* tools in that it doesn't tie us to past design
(mis)choices.  This commit mostly deals with rearranging code, although
there was a considerable amount of rewriting done in cases where I
thought the code was somewhat messy and was difficult to understand.

The design I chose for supporting multiple package system flavors is
that the various depends, install, package, etc.  modules would define
default targets and variables that may be overridden in files from
pkgsrc/mk/flavor/${PKG_FLAVOR}.  The default targets would do the
sensible thing of doing nothing, and pkgsrc infrastructure would rely
on the appropriate things to be defined in pkgsrc/mk/flavor to do the
real work.  The pkgsrc/mk/flavor directory contains subdirectories
corresponding to each package system flavor that we support.  Currently,
I only have "pkg" which represents the current pkgsrc-native package
flavor.  I've separated out most of the code where we make assumptions
about the package system flavor, mostly either because we directly
use the pkg_* tools, or we make assumptions about the package meta-data
directory, or we directly manipulate the package meta-data files, and
placed it into pkgsrc/mk/flavor/pkg.

There are several new modules that have been refactored out of bsd.pkg.mk
as part of these changes: check, depends, install, package, and update.
Each of these modules has been slimmed down by rewriting them to avoid
some recursive make calls.  I've also religiously documented which
targets are "public" and which are "private" so that users won't rely
on reaching into pkgsrc innards to call a private target.

The "depends" module is a complete overhaul of the way that we handle
dependencies.  There is now a separate "depends" phase that occurs
before the "extract" phase where dependencies are installed.  This
differs from the old way where dependencies were installed just before
extraction occurred.  The reduce-depends.mk file is now replaced by
a script that is invoked only once during the depends phase and is
used to generate a cookie file that holds the full set of reduced
dependencies.  It is now possible to type "make depends" in a package
directory and all missing dependencies will be installed.

Future work on this project include:

    * Resolve the workflow design in anticipation of future work on
      staged installations where "package" conceptually happens before
      "install".

    * Rewrite the buildlink3 framework to not assume the use of the
      pkgsrc pkg_* tools.

    * Rewrite the pkginstall framework to provide a standard pkg_*
      tool to perform the actions, and allowing a purely declarative
      file per package to describe what actions need to be taken at
      install or deinstall time.

    * Implement support for the SVR4 package flavor.  This will be
      proof that the appropriate abstractions are in place to allow
      using a completely different set of package management tools.
2006-06-03 23:11:42 +00:00