then automatically generate a PLIST that says "${PKGNAME} has no files".
* If PLIST_SRC and GENERATE_PLIST are not set in a package Makefile,
and no PLIST files exist, then fail during the package build with
PKG_FAIL_REASON.
* Remove "intentionally empty" PLISTs again.
Now, the easy way to say that a package installs no files is to just
add the following to the package Makefile:
PLIST_SRC= # empty
that directly manipulate empty PLISTs.
Modify plist/plist.mk so that if the PLIST files are missing and no
GENERATE_PLIST is defined, then the package fails to build.
RECOMMENDED is removed. It becomes ABI_DEPENDS.
BUILDLINK_RECOMMENDED.foo becomes BUILDLINK_ABI_DEPENDS.foo.
BUILDLINK_DEPENDS.foo becomes BUILDLINK_API_DEPENDS.foo.
BUILDLINK_DEPENDS does not change.
IGNORE_RECOMMENDED (which defaulted to "no") becomes USE_ABI_DEPENDS
which defaults to "yes".
Added to obsolete.mk checking for IGNORE_RECOMMENDED.
I did not manually go through and fix any aesthetic tab/spacing issues.
I have tested the above patch on DragonFly building and packaging
subversion and pkglint and their many dependencies.
I have also tested USE_ABI_DEPENDS=no on my NetBSD workstation (where I
have used IGNORE_RECOMMENDED for a long time). I have been an active user
of IGNORE_RECOMMENDED since it was available.
As suggested, I removed the documentation sentences suggesting bumping for
"security" issues.
As discussed on tech-pkg.
I will commit to revbump, pkglint, pkg_install, createbuildlink separately.
Note that if you use wip, it will fail! I will commit to pkgsrc-wip
later (within day).
and replace with appropriate references to PKGINFODIR instead.
* Properly account for split info files during installation.
* Move info file listings directly into the package PLISTs.
This fixes info-file-related PLIST problems.
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
All library names listed by *.la files no longer need to be listed
in the PLIST, e.g., instead of:
lib/libfoo.a
lib/libfoo.la
lib/libfoo.so
lib/libfoo.so.0
lib/libfoo.so.0.1
one simply needs:
lib/libfoo.la
and bsd.pkg.mk will automatically ensure that the additional library
names are listed in the installed package +CONTENTS file.
Also make LIBTOOLIZE_PLIST default to "yes".
the resulting shared library names don't necessarily match the NetBSD
names. Instead of hardcoding the shared library names in the PLISTs,
only list the libtool archives in the PLISTs and dynamically determine
the shared library names at post-install time and insert them into
the PLIST. This fixes PLIST errors on non-NetBSD platforms.
All of the magic is done in pkgsrc/lang/gcc3/language.mk. This should
probably be generalized into something that could be used by all
packages that use libtool.
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.
Update gcc3-c++ to 3.3.3nb1
Update gcc3-c to 3.3.3nb2
Update gcc3-f77 to 3.3.3nb1
Update gcc3-java to 3.3.3nb1
Update gcc3-objc to 3.3.3nb1
Update gcc3 to 3.3.3nb1
gcc arm: fix GCC _P_R_ target/14302
Apply gcc fix for gcc PR target/14302 to fix ARM compiler
issues triggered by at least glib, glib2, and pkgconfig.
2004-02-26 Richard Earnshaw <rearnsha@arm.com>
Daniel Jacobowitz <drow@mvista.com>
PR target/14302
* arm.h (ARM_GO_IF_LEGITIMATE_ADDRESS): Don't check the mode
size for minipool references.
IRIX system we are on, gcc can NOT be compiled (bootstrapped) as a
64bit binary. Fortunately, IRIX64 can handle 32bit binaries, so that we
can force use of 32bit when using MIPSPro.
This allows gcc3-c to build fine under IRIX and IRIX64.
