When using GH_TAGNAME the DISTNAME would have GH_PROJECT and GH_ACCOUNT in
it. When not using GH_TAGNAME it would not have this. Now both cases
will add in the GH_PROJECT and GH_ACCOUNT.
Add special care to ensure that the DISTVERSION is not added in twice. If
a port does GH_TAGNAME=v${PORTVERSION} it will be added in twice though. For
that case DISTVERSIONPREFIX=v should be set and no GH_TAGNAME should be used.
empty() is used rather than (!defined || !${}) to support fmake.
The purpose of setting DISTNAME at all in these cases is to make it more clear
that the distfile is from *GITHUB* and to avoid collisions if a project were
to be renamed or moved. Without adding in GH_PROJECT and GH_ACCOUNT then there
are real risks that collisions on filenames would happen on renamed or moved
projects, which is fairly common. A GITHUB-generated file may not match
a custom-rolled or git-archive-rolled distfile.
PR: 199069
With hat: portmgr
Testing done: All USE_GITHUB ports without GH_COMMIT were checksum/fetch/extract/WRKSRC tested.
gdb66 and insight neither build with -pg nor link any other _p library.
For profiling to work the ports may also need to disable stripping of
non-debug symbols, build with -fno-omit-frame-pointer and do so for all
the dependencies as well.
poudriere fails because before 9.0R proflibs were packaged separately
not in DIST list for |jail -c|, and 11.0C removed libreadline while
devel/readline doesn't provide _p variant.
Reported by: pkg-fallout (-quaterly lacks 84* and head* slaves)
Approved by: portmgr blanket
MFH: 2015Q2
Add an XFCE SITE_SUBDIR abbreviation and use it forf or the xfce ports,
which removes the need to set MASTER_SITE_SUBDIR in any of them.
This fixes ports that have USES=xfce but do not use the XFCE MASTER_SITE,
namely sysutils/xfce4-bsdcpufreq-plugin.
With hat: portmgr
- the incremental parser didn't properly parse tagged values
(testcase by Mons Anderson).
- slightly speed up encoding of plain (nonmagical) arrays.
- try to clarify further that effectively all 32 bit architectures
have 64 bit integer support.
- upgrade libecb
PR: 199759
Submitted by: adamw
The original intention was to build update all the bootstrap compilers
to be based on GCC5, but right now I'm only doing that for DragonFly.
After June 30, I might rebuild the bootstrap compiler on FreeBSD 10.1,
but right now gcc5-aux is building fine on FreeBSD in one stage, even
though their bootstrap is based on GCC 4.9.
Right now, gcc5-aux is building with 3 full stages. I'm switching it to
a single stage build, but adding an off-by-default option to build it
in three stages again. With one stage, libcc1 is not built, but with
three stages it is. LibCC1 is meant to support the upcoming release of
GDB so it's currently not needed (it fails to build if gcc is not fully
bootstrapping which is why it's disabled)
This brings the build down to about 9-14 minutes versus 60-90 minutes
depending on the (average power) machine.
Also, I've explicitly limited the build to i386 and amd64 on FreeBSD and
I have dropped i386 support on DragonFly, which could only have been
build on DragonFly 3.8 or earlier.
Also, I removed the iconv dependency when a bootstrap compiler is being
created (the all-overriding BOOTSTRAP option for the maintainer)
on base and can confuses ports system not installing security/krb5. No bump on
PORTREVISION since it's disabled by default
Approved by: zi@
Sponsored by: Netgate
Swapping LIBS with LDFLAGS and removing the *_configargs definitions
allows gcc5-aux to build on all supported platforms. Now that gcc5 has
been released, new bootstrap compilers should be created for both FreeBSD
and DragonFly in order remove bootstrapping requirement (previously
gcc5 built live but not in poudriere, reason still unknown).
Now that the JAVA exclusion is part of the main Makefile, the only thing
Makefile.DragonFly was doing was supporting pre-gcc5 dev branch. Those
users have a static package available to them, and in general they are
expected to upgrade to post-gcc5 in base anyway. Thus the DF makefile
is no longer necessary.
Changelog:
* Improved reporting of invalid chunk names. Does not try to put
non-printable characters in STDERR; displays hex numbers instead.
* Fixed include path for utime.h on MSVC (Louis McLaughlin).
* Eliminated "FAR" memory support (it was removed from libpng at version
1.6.0).
* Disabled the "-already_crushed" option which does not really work well.
PR: ports/199520
Submitted by: Anton Sayetsky <vsasjason@gmail.com> (maintainer)
iTop stands for IT Operational Portal.
iTop is an Open Source web application for the day to day operations
of an IT environment. iTop was designed with the ITIL best practices
in mind but does not dictate any specific process, the application
is flexible enough to adapt to your processes whether you want rather
informal and pragmatic processes or a strict ITIL aligned behavior.
WWW: http://www.combodo.com/
PR: ports/199646
Submitted by: olevole@olevole.ru
The default mode for C is now -std=gnu11 instead of -std=gnu89.
New warning options -Wc90-c99-compat and -Wc99-c11-compat may
prove useful on that front.
The C++ front end now has full C++14 language support including
C++14 variable templates, C++14 aggregates with non-static data
member initializers, C++14 extended constexpr, and more.
The Standard C++ Library (libstdc++) has full C++11 support and
experimental full C++14 support. It uses a new ABI by default.
There have been significant improvements to inter-procedural optimizations
and link-time optimization such as One Definition Rule based merging of C++
types as well as register allocation.
OpenMP 4.0 specification offloading features are now supported by the C,
C++, and Fortran compilers. Cilk Plus, an extension to the C and C++
languages to support data and task parallelism, has been added as well.
New warning options -Wswitch-bool, -Wlogical-not-parentheses,
-Wbool-compare and -Wsizeof-array-argument may prove useful as
may new preprocessor directives __has_include, __has_include_next,
and __has_attribute.
GCC can now be built as a shared library for embedding in other processes
(such as interpreters), suitable for Just-In-Time compilation to machine
code. This provides a C API and a C++ wrapper API.
Many code generation improvements for AArch64, ARM, support for
AVX-512{BW,DQ,VL,IFMA,VBMI} and Intel MPX on x86-64, and generally
improvements on many targets.
The Local Register Allocator (LRA) now contains a rematerialization
subpass and is able to reuse the PIC hard register on x86/x86-64 to
improve performance of position independent code.
https://gcc.gnu.org/gcc-5/changes.html has a more extensive set of
changes and https://gcc.gnu.org/gcc-5/porting_to.html has a solid
overview of issue you may encountering porting to this new version.
