to the versioned executable (gfortran48, gcc48, and g++48).
These standard names are going to remain in place in case of version
upgrades and constitute the default, and expected by users, names.
Suggested by: db
Reviewed by: db
This change is the same as r400632, which updated gcc[56]-devel, but now
for gcc{,48,49,5}. This change is the second attempt at doing this: the
first attempt went in r401072 and was reverted in r401074 because the diff
was bogus and enabled the new MULTILIB option under all platforms instead
of just powerpc64.
This fixes the build of gcc{,48,49,5} under powerpc64 when the system
is built without the lib32 libraries.
More in detail:
If the system is built with lib32 support (WITH_LIB32, which is the default),
building gcc from ports results in a compiler that can target both 64-bit and
32-bit binaries on powerpc64. However, when lib32 support is disabled
(WITHOUT_LIB32), gcc should only be built with 64-bit support or otherwise
the build fails.
To fix this, explicitly disable 32-bit support when /usr/lib32 is not present
and add a MULTILIB option (which is only defined for powerpc64 when 32-bit
support is possible and defaults to yes to preserve the current behavior) to
allow the user to explicitly control this feature.
Approved by: gerald (maintainer), bdrewery (mentor), andreast
Differential Revision: https://reviews.freebsd.org/D3952
- update to 2.7.0
- change MASTER_SITES to use https and modern mirror as suggested by [1]
- Jython uses two licenses, indicate that in the port. Extract the licenses from
the jar earlier so ports framework can find them
- the port complains when trying to build with openjdk6, so set JAVA_VERSION
to 1.7+
- mark NO_ARCH
- null the PATH for installer invocation. If installer finds python2.7 in PATH
it installs python wrapper script instead of bash one. [2]
- exclude "ensurepip" module from the installation as it doesn't build on FreeBSD
- change kinda dirty and not obvious replacement of "-cl"(asspath) to addition
to JAVA_OPTS. This hack is needed to place jython cachedir into user's home
directory, as it needs to be writable by the user invoking jython
- write comments to not obvious parts of the installation
- wrapper script is now placed in bin/ directory in JYTHON_PREFIX rather then
in root, fix that
- Jython uses *$py.class files as an analog for *.pyc ones in plain Python,
installer puts pre-compiled *$py.class files into the STAGEDIR. We need to
recompile that because, after installation:
1) If we invoke Jython as user - it can't use the *$py.class files as they
have different source path inside, slowing down the startup;
2) If we invoke jython as root - it will recompile the *$py.class files
breaking the de-installation process of the package. Compilation phase
always have non-portrelated errors, so we need to ignore it's exit code
- Don't ignore the exit code of symlink installation as we don't expect that to fail
[1] https://central.maven.org/
[2] https://hg.python.org/jython/file/tip/installer/src/java/org/python/util/install/StartScriptGenerator.java#l22
PR: 204231
Submitted by: Sergey Kozlov <kozlov.sergey.404@gmail.com>
non-default Python versions:
- Add pyXY-{sqlite3,gdbm,tkinter} ports for generating binary packages
- Improve/add pkg-message to point users to install respective packages of
separated Python standard modules
- Add COMMENT to explicitly show the Python version that package should be
used with
- Simplify version-related PYTHON_* for lang/python35
Reviewed by: koobs
Differential Revision: https://reviews.freebsd.org/D4170
The upstream distfile was changed. Most of the changes were regenerated
documentation, but a build file (gpr) was also updated. The changes are
legitimate (but should have been provided r4)
Introduce DIST_SUBDIR now that adacontrol joined the reroll club.
This port was establishing WRKDIR over bpm. The reason why wasn't good;
There is a home-grown pattern replacement in the port. I replaced the
custom sed command with REINPLACE_CMD as minimally as I could, and then
removed the WRKDIR redefinition.
Approved by: just fix it
During the conversion to use option handlers, I found a couple of
typos and obsolete code which caused errors. I also switched to
USES+= readline libedit when their options were selected.
The previous depends declaration for libedit was incorrect. It had a
".so" prefix instead of ".so.0" prefix meaning that the requirement
would have been satisfied by system libedit. For this reason, converting
to USES=libedit requires a bump.
Approved by: infrastructure modernization
I'm not sure what happened exactly but I think I committed the change from
the wrong client. The applied change enabled the MULTILIB option for all
architectures and not only powerpc64. Let's just revert the commit and do
it properly from scratch; other things might be wrong so I wanna take a
closer look, and it's best to just revert quickly.
This change is the same as r400632, which updated gcc[56]-devel, but now
for gcc{,48,49,5}. Waited a week to ensure the change caused nothing to go
horribly wrong but this change is very low risk because it only affects
powerpc64.
This fixes the build of gcc{,48,49,5} under powerpc64 when the system
is built without the lib32 libraries.
More in detail:
If the system is built with lib32 support (WITH_LIB32, which is the default),
building gcc from ports results in a compiler that can target both 64-bit and
32-bit binaries on powerpc64. However, when lib32 support is disabled
(WITHOUT_LIB32), gcc should only be built with 64-bit support or otherwise
the build fails.
To fix this, explicitly disable 32-bit support when /usr/lib32 is not present
and add a MULTILIB option (which is only defined for powerpc64 when 32-bit
support is possible and defaults to yes to preserve the current behavior) to
allow the user to explicitly control this feature.
Approved by: gerald (maintainer), bdrewery (mentor), andreast
Differential Revision: https://reviews.freebsd.org/D3952
- Provide target for 'make test': Use bundled rust regression test suite
- Use bundled LLVM for now: Built with it, rust passes more regression tests
- Bump PORTREVISION
