ports/sysutils/cdrdao, branch 6-eolFreeBSD ports treehttps://cgit-dev.freebsd.org/ports/atom?h=6-eol2010-06-06T20:39:21ZBump PORTREVISION after libao update and handle API incompatibility.2010-06-06T20:39:21ZChristian Weisgerbernaddy@FreeBSD.org2010-06-06T20:39:21Zurn:sha1:f613ac049d40272c3b27a76dbab7f6723f2a2ba2Build and use the internal pccts in order avoid the conflict between2010-05-02T12:43:48ZMarius Stroblmarius@FreeBSD.org2010-05-02T12:43:48Zurn:sha1:196aff031edd84ee55dfce8ff6338e459edd472c
devel/antlr and devel/pccts. Generally this doesn't fix anything of
course, given that there's only one other port which still requires
devel/pccts instead of its successor it makes sense to avoid that
dependency.
Approved by: netchild
PR: 145615
Ressurect MASTER_SITE_SUBDIR which erroneously got nuked in rev. 1.572009-10-30T19:27:21ZMarius Stroblmarius@FreeBSD.org2009-10-30T19:27:21Zurn:sha1:97480db01a59a861f5aaee905d11023968ee8f9d
but actually is needed for the gcdmaster slave-port.
Approved by: netchild
Update to 1.2.3.2009-10-25T14:52:40ZMarius Stroblmarius@FreeBSD.org2009-10-25T14:52:40Zurn:sha1:17987482200dec0b435955b05a79c3b7d076ea4f
Approved by: netchild
Hardcode a compiler specification file so CC can also be set to something2009-09-12T18:56:36ZMarius Stroblmarius@FreeBSD.org2009-09-12T18:56:36Zurn:sha1:a5b2af30a40094b5494749755c7e672437a60f14
containing spaces.
Approved by: netchild
- Retire MASTER_SITE_SOURCEFORGE_EXTENDED, it's no longer needed - all mirrors actually have all distfiles2009-09-02T15:01:56ZDmitry Marakasovamdmi3@FreeBSD.org2009-09-02T15:01:56Zurn:sha1:535382b89150108fea8bdf4a729e9ed1257f42f8
- Merge all SF mirrors to MASTER_SITE_SOURCEFORGE, resort according to quick download speed survey
- Fix MASTER_SITES for all port that have used SOURCEFORGE_EXTENTED
Approved by: portmgr (pav)
Bump PORTREVISION after libogg and libvorbisfile major version increment.2009-07-06T21:25:59ZChristian Weisgerbernaddy@FreeBSD.org2009-07-06T21:25:59Zurn:sha1:94d47b2ecd581b68ef0e363f9ff1145074acc0a0Update CONFIGURE_ARGS for how we pass CONFIGURE_TARGET to configure script.2008-08-21T06:18:49ZRong-En Fanrafan@FreeBSD.org2008-08-21T06:18:49Zurn:sha1:741aa714833b9bb1e9afaaf5124d3f5c60b5e49c
Specifically, newer autoconf (> 2.13) has different semantic of the
configure target. In short, one should use --build=CONFIGURE_TARGET
instead of CONFIGURE_TARGET directly. Otherwise, you will get a warning
and the old semantic may be removed in later autoconf releases.
To workaround this issue, many ports hack the CONFIGURE_TARGET variable
so that it contains the ``--build='' prefix.
To solve this issue, under the fact that some ports still have
configure script generated by the old autoconf, we use runtime detection
in the do-configure target so that the proper argument can be used.
Changes to Mk/*:
- Add runtime detection magic in bsd.port.mk
- Remove CONFIGURE_TARGET hack in various bsd.*.mk
- USE_GNOME=gnometarget is now an no-op
Changes to individual ports, other than removing the CONFIGURE_TARGET hack:
= pkg-plist changed (due to the ugly CONFIGURE_TARGET prefix in * executables)
- comms/gnuradio
- science/abinit
- science/elmer-fem
- science/elmer-matc
- science/elmer-meshgen2d
- science/elmerfront
- science/elmerpost
= use x86_64 as ARCH
- devel/g-wrap
= other changes
- print/magicfilter
GNU_CONFIGURE -> HAS_CONFIGURE since it's not generated by autoconf
Total # of ports modified: 1,027
Total # of ports affected: ~7,000 (set GNU_CONFIGURE to yes)
PR: 126524 (obsoletes 52917)
Submitted by: rafan
Tested on: two pointyhat 7-amd64 exp runs (by pav)
Approved by: portmgr (pav)
Rename fexecve() to js_fexecve() so it doesn't clash with the recently2008-04-09T20:40:00ZMarius Stroblmarius@FreeBSD.org2008-04-09T20:40:00Zurn:sha1:b4937943626417f469b7578fe6d5fa67eab4a58f
added libc one.
Reported by: marcus
Approved by: netchild
Fix the build with new libsigc++20 2.2.2. I have tested these ports in runtime2008-03-28T01:50:20ZJeremy Messengermezz@FreeBSD.org2008-03-28T01:50:20Zurn:sha1:01aa5d3c3738157ac5f482617e3d1ef1ec50bfba
and these seem work fine in normal use. I don't test every functions, so let
me know if you have any problem with it.
Reported by: pointyhat via pav