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)
The affected ports are the ones with gettext as a run-dependency
according to ports/INDEX-7 (5007 of them) and the ones with USE_GETTEXT
in Makefile (29 of them).
PR: ports/124340
Submitted by: edwin@
Approved by: portmgr (pav)
gpsim is a full-featured software simulator for Microchip PIC microcontrollers
distributed under the GNU General Public License.
gpsim has been designed to be as accurate as possible. Accuracy includes the
entire PIC - from the core to the I/O pins and including ALL of the internal
peripherals. Thus it's possible to create stimuli and tie them to the I/O pins
and test the PIC the same PIC the same way you would in the real world.
gpsim has been designed to be as fast as possible. Real time simulation speeds
of 20Mhz pics are possible. A 'goto $' program runs at the same speed as a
25Mhz pic when simulated on my 400Mhz PII Linux Box. Of course, as you add
stimuli and begin interacting with peripherals, the performance drops. But
it's still fast!
gpsim has been designed to be as useful as possible (at least that's the
intent - honest). The standard simulation paradigm including breakpoints,
single stepping, disassembling, memory inspect & change, and so on has been
implemented. In addition, gpsim supports many debugging features that are only
available with in-circuit emulators. For example, a continuous trace buffer
tracks every action of the simulator (whether you want it or not). Also, it's
possible to set read and write break points on values (e.g. break if a
specific value is read from or written to a register).
WWW: http://www.dattalo.com/gnupic/gpsim.html
PR: ports/94436
Submitted by: Jose Alonso Cardenas Marquez <acardenas@bsd.org.pe>
