<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Makefile</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>f5e04876 - MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346081,r346270,r346574,r346576:</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++experimental/Makefile#f5e04876</link>
        <description>MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346081,r346270,r346574,r346576:r345203:Initial googlemock/googletest integration into the build/FreeBSD test suiteThis initial integration takes googlemock/googletest release 1.8.1, integratesthe library, tests, and sample unit tests into the build.googlemock/googletest&apos;s inclusion is optionally available via `MK_GOOGLETEST`.`MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default whenbuilt with a C++11 capable toolchain.Google tests can be specified via the `GTESTS` variable, which, in comparisonwith the other test drivers, is more simplified/streamlined, as Googletest onlysupports C++ tests; not raw C or shell tests (C tests can be written in C++using the standard embedding methods).No dependent libraries are assumed for the tests. One must specify `gmock`,`gmock_main`, `gtest`, or `gtest_main`, via `LIBADD` for the program.More information about googlemock and googletest can be found on theGoogletest [project page](https://github.com/google/googletest), and the[GoogleMock](https://github.com/google/googletest/blob/v1.8.x/googlemock/docs/Documentation.md)and[GoogleTest](https://github.com/google/googletest/tree/v1.8.x/googletest/docs)docs.These tests are originally integrated into the build as plain driver tests, butwill be natively integrated into Kyua in a later version.Known issues/Errata:* [WhenDynamicCastToTest.AmbiguousCast fails on FreeBSD](https://github.com/google/googletest/issues/2172)r345205:Integrate cddl/usr.sbin/zfds/tests into the FreeBSD test suiteThis change integrates the unit tests for zfsd into the test suite using theintegration method described in r345203.This change removes the `LOCALBASE` includes added for the port version ofgooglemock/googletest, as well as unnecessary `LIBADD`/`DPADD` and `CXXFLAGS`defines, which are included in the `GTEST_CXXFLAGS` variable, as part ofr345203.r345353 (by asomers):googletest: backport GTEST_SKIP to googletest 1.8.1This commit backports revisions 00938b2b228f3b70d3d9e51f29a1505bdad43f1e and59f90a338bce2376b540ee239cf4e269bf6d68ad from googletest&apos;s master branch toour included version of googletest, which is based on 1.8.1. It adds theGTEST_SKIP feature, which is very useful for a project like FreeBSD wheresome tests depend on particular system configurations.Obtained from:	github.com/google/googletestr345645:Spam CXXFLAGS with `-I${DESTDIR}/usr/include/private`, instead of GTEST_CXXFLAGSThis makes it easier for googletest users to leverage googletest, instead offorcing them to plug GTEST_CXXFLAGS into CXXFLAGS manually (resulting inunnecessary duplication).I will be following this up with a more proper fix in src.libnames.mk, assrc.libnames.mk should be automatically adding this directory toCFLAGS/CXXFLAGS when private libraries are referenced. Not doing so can resultin mismatches between base-provided private library&apos;s and ports-providedlibrary&apos;s headers.While here, tweak the comment to clarify what the intent is behind spammingCXXFLAGS.r345708:Standardize `-std=c++* as `CXXSTD`CXXSTD was added as the C++ analogue to CSTD.CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,otherwise for older versions of g++.This change standardizes the CXXSTD variable, originally added togoogletest.test.inc.mk as part of r345203.As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.Notes:This value is not sanity checked in bsd.sys.mk, however, given the twomost used C++ compilers on FreeBSD (clang++ and g++) support both modes, it islikely to work with both toolchains. This method will be refined in the futureto support more variants of C++, as not all versions of clang++ and g++ (forinstance) support C++14, C++17, etc.Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.Example:Before this commit:```CXXFLAGS+=	-std=c++14```After this commit:```CXXSTD=	c++14```Relnotes:	yesTested with:	make tinderboxr345709:Allow users to override CSTD/CXXSTD on a per-prog basisThe current logic for CSTD/CXXSTD requires homogenity as far as thesupported C/C++ standards, which is a sensible default. However, whendealing with differing versions of C++, some code may compile with C++11, butnot C++17 (for instance). So in order to avoid having people convert over theircode to the new standard, give the users the ability to specify the standard ona per-program basis.This will allow a user to override the supporting standard for a set ofprograms, mixing C++11 with C++14 (for instance).Apprved by:	emaste (mentor)r345735:Allow programs to set `NO_SHARED` on a per-PROG basisThis is particularly useful when installing programs for tests that need to belinked statically, e.g., mini-me from capsicum-test, which is linked staticallyto avoid the dynamic library lookup in the upstream project.r345770:Import proof-of-concept for handling `GTEST_SKIP()` in `Environment::SetUp`Per the upstream pull-request [1]:```  gtest prior to this change would completely ignore `GTEST_SKIP()` if  called in `Environment::SetUp()`, instead of bailing out early, unlike  `Test::SetUp()`, which would cause the tests themselves to be skipped.  The only way (prior to this change) to skip the tests would be to  trigger a fatal error via `GTEST_FAIL()`.  Desirable behavior, in this case, when dealing with  `Environment::SetUp()` is to check for prerequisites on a system  (example, kernel supports a particular featureset, e.g., capsicum), and  skip the tests. The alternatives prior to this change would be  undesirable:  - Failing sends the wrong message to the test user, as the result of the    tests is indeterminate, not failed.  - Having to add per-test class abstractions that override `SetUp()` to    test for the capsicum feature set, then skip all of the tests in their    respective SetUp fixtures, would be a lot of human and computational    work; checking for the feature would need to be done for all of the    tests, instead of once for all of the tests.  For those reasons, making `Environment::SetUp()` handle `GTEST_SKIP()`,  by not executing the testcases, is the most desirable solution.  In order to properly diagnose what happened when running the tests if  they are skipped, print out the diagnostics in an ad hoc manner.  Update the documentation to note this change and integrate a new test,  gtest_skip_in_environment_setup_test, into the test suite.  This change addresses #2189.  Signed-off-by: Enji Cooper &lt;yaneurabeya@gmail.com&gt;```The goal with my merging in this change is to avoid requiring extensiverefactoring/retesting of test suites when ensuring prerequisites are met,e.g., checking for a CAPABILITIES-enabled kernel before running capsicum-test(see D19758 for more details).The proof-of-concept is being imported before accepted by the upstreamproject due to the fact that the upstream project is undergoing a potentialdevelopment freeze and the maintainers aren&apos;t responding to my PR.1. https://github.com/google/googletest/pull/2203r346081 (by trasz):Make zfsd(8) build obey CFLAGS.Obtained from:	CheriBSDr346270 (by trasz):Drop -g from CFLAGS for zfsd(8).  No idea why it was ever there.r346574:Rework CXXSTD setting via r345708This change allows the user to once again override the C++ standard, restoringhigh-level pre-r345708 behavior.This also unbreaks building lib/ofed/libibnetdisc/Makefile with a non-C++11capable compiler, e.g., g++ 4.2.1, as the library supported being built witholder C++ standards.r346576:Fix up CXXSTD support originally added in r345708r345708 worked for the base system, but unfortunately, caused a lot ofdisruption for third-party packages that relied on C++, since bsd.sys.mk isused by applications outside the base system. The defaults picked didn&apos;t matchthe compiler&apos;s defaults and broke some builds that didn&apos;t specify a standard,as well as some that overrode the value by setting `-std=gnu++14` (forexample) manually.This change takes a more relaxed approach to appending `-std=${CXXSTD}` toCXXFLAGS, by only doing so when the value is specified, as opposed tooverriding the standard set by an end-user. This avoids the need for havingto bake NOP default into bsd.sys.mk for supported compiler-toolchainversions.In order to make this change possible, add CXXSTD to Makefile snippets whichrelied on the default value (c++11) added in r345708.

            List of files:
            /freebsd-12.1/lib/libc++experimental/Makefile</description>
        <pubDate>Thu, 23 May 2019 01:09:10 +0000</pubDate>
        <dc:creator>Enji Cooper &lt;ngie@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>df407fbc - Revert r348136</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++experimental/Makefile#df407fbc</link>
        <description>Revert r348136I accidentally committed some unrelated local changes to`.../tests/sys/opencrypto` along with this MFC set.

            List of files:
            /freebsd-12.1/lib/libc++experimental/Makefile</description>
        <pubDate>Thu, 23 May 2019 00:59:05 +0000</pubDate>
        <dc:creator>Enji Cooper &lt;ngie@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>e787ffab - MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346574,r346576:</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++experimental/Makefile#e787ffab</link>
        <description>MFC r345203,r345205,r345353,r345645,r345708,r345709,r345735,r345770,r346574,r346576:r345203:Initial googlemock/googletest integration into the build/FreeBSD test suiteThis initial integration takes googlemock/googletest release 1.8.1, integratesthe library, tests, and sample unit tests into the build.googlemock/googletest&apos;s inclusion is optionally available via `MK_GOOGLETEST`.`MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default whenbuilt with a C++11 capable toolchain.Google tests can be specified via the `GTESTS` variable, which, in comparisonwith the other test drivers, is more simplified/streamlined, as Googletest onlysupports C++ tests; not raw C or shell tests (C tests can be written in C++using the standard embedding methods).No dependent libraries are assumed for the tests. One must specify `gmock`,`gmock_main`, `gtest`, or `gtest_main`, via `LIBADD` for the program.More information about googlemock and googletest can be found on theGoogletest [project page](https://github.com/google/googletest), and the[GoogleMock](https://github.com/google/googletest/blob/v1.8.x/googlemock/docs/Documentation.md)and[GoogleTest](https://github.com/google/googletest/tree/v1.8.x/googletest/docs)docs.These tests are originally integrated into the build as plain driver tests, butwill be natively integrated into Kyua in a later version.Known issues/Errata:* [WhenDynamicCastToTest.AmbiguousCast fails on FreeBSD](https://github.com/google/googletest/issues/2172)r345205:Integrate cddl/usr.sbin/zfds/tests into the FreeBSD test suiteThis change integrates the unit tests for zfsd into the test suite using theintegration method described in r345203.This change removes the `LOCALBASE` includes added for the port version ofgooglemock/googletest, as well as unnecessary `LIBADD`/`DPADD` and `CXXFLAGS`defines, which are included in the `GTEST_CXXFLAGS` variable, as part ofr345203.r345353 (by asomers):googletest: backport GTEST_SKIP to googletest 1.8.1This commit backports revisions 00938b2b228f3b70d3d9e51f29a1505bdad43f1e and59f90a338bce2376b540ee239cf4e269bf6d68ad from googletest&apos;s master branch toour included version of googletest, which is based on 1.8.1. It adds theGTEST_SKIP feature, which is very useful for a project like FreeBSD wheresome tests depend on particular system configurations.Obtained from:	github.com/google/googletestr345645:Spam CXXFLAGS with `-I${DESTDIR}/usr/include/private`, instead of GTEST_CXXFLAGSThis makes it easier for googletest users to leverage googletest, instead offorcing them to plug GTEST_CXXFLAGS into CXXFLAGS manually (resulting inunnecessary duplication).I will be following this up with a more proper fix in src.libnames.mk, assrc.libnames.mk should be automatically adding this directory toCFLAGS/CXXFLAGS when private libraries are referenced. Not doing so can resultin mismatches between base-provided private library&apos;s and ports-providedlibrary&apos;s headers.While here, tweak the comment to clarify what the intent is behind spammingCXXFLAGS.r345708:Standardize `-std=c++* as `CXXSTD`CXXSTD was added as the C++ analogue to CSTD.CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,otherwise for older versions of g++.This change standardizes the CXXSTD variable, originally added togoogletest.test.inc.mk as part of r345203.As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.Notes:This value is not sanity checked in bsd.sys.mk, however, given the twomost used C++ compilers on FreeBSD (clang++ and g++) support both modes, it islikely to work with both toolchains. This method will be refined in the futureto support more variants of C++, as not all versions of clang++ and g++ (forinstance) support C++14, C++17, etc.Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.Example:Before this commit:```CXXFLAGS+=	-std=c++14```After this commit:```CXXSTD=	c++14```Relnotes:	yesTested with:	make tinderboxr345709:Allow users to override CSTD/CXXSTD on a per-prog basisThe current logic for CSTD/CXXSTD requires homogenity as far as thesupported C/C++ standards, which is a sensible default. However, whendealing with differing versions of C++, some code may compile with C++11, butnot C++17 (for instance). So in order to avoid having people convert over theircode to the new standard, give the users the ability to specify the standard ona per-program basis.This will allow a user to override the supporting standard for a set ofprograms, mixing C++11 with C++14 (for instance).Approved by:	emaste (mentor)r345735:Allow programs to set `NO_SHARED` on a per-PROG basisThis is particularly useful when installing programs for tests that need to belinked statically, e.g., mini-me from capsicum-test, which is linked staticallyto avoid the dynamic library lookup in the upstream project.r345770:Import proof-of-concept for handling `GTEST_SKIP()` in `Environment::SetUp`Per the upstream pull-request [1]:```  gtest prior to this change would completely ignore `GTEST_SKIP()` if  called in `Environment::SetUp()`, instead of bailing out early, unlike  `Test::SetUp()`, which would cause the tests themselves to be skipped.  The only way (prior to this change) to skip the tests would be to  trigger a fatal error via `GTEST_FAIL()`.  Desirable behavior, in this case, when dealing with  `Environment::SetUp()` is to check for prerequisites on a system  (example, kernel supports a particular featureset, e.g., capsicum), and  skip the tests. The alternatives prior to this change would be  undesirable:  - Failing sends the wrong message to the test user, as the result of the    tests is indeterminate, not failed.  - Having to add per-test class abstractions that override `SetUp()` to    test for the capsicum feature set, then skip all of the tests in their    respective SetUp fixtures, would be a lot of human and computational    work; checking for the feature would need to be done for all of the    tests, instead of once for all of the tests.  For those reasons, making `Environment::SetUp()` handle `GTEST_SKIP()`,  by not executing the testcases, is the most desirable solution.  In order to properly diagnose what happened when running the tests if  they are skipped, print out the diagnostics in an ad hoc manner.  Update the documentation to note this change and integrate a new test,  gtest_skip_in_environment_setup_test, into the test suite.  This change addresses #2189.  Signed-off-by: Enji Cooper &lt;yaneurabeya@gmail.com&gt;```The goal with my merging in this change is to avoid requiring extensiverefactoring/retesting of test suites when ensuring prerequisites are met,e.g., checking for a CAPABILITIES-enabled kernel before running capsicum-test(see D19758 for more details).The proof-of-concept is being imported before accepted by the upstreamproject due to the fact that the upstream project is undergoing a potentialdevelopment freeze and the maintainers aren&apos;t responding to my PR.1. https://github.com/google/googletest/pull/2203r346574:Rework CXXSTD setting via r345708This change allows the user to once again override the C++ standard, restoringhigh-level pre-r345708 behavior.This also unbreaks building lib/ofed/libibnetdisc/Makefile with a non-C++11capable compiler, e.g., g++ 4.2.1, as the library supported being built witholder C++ standards.r346576:Fix up CXXSTD support originally added in r345708r345708 worked for the base system, but unfortunately, caused a lot ofdisruption for third-party packages that relied on C++, since bsd.sys.mk isused by applications outside the base system. The defaults picked didn&apos;t matchthe compiler&apos;s defaults and broke some builds that didn&apos;t specify a standard,as well as some that overrode the value by setting `-std=gnu++14` (forexample) manually.This change takes a more relaxed approach to appending `-std=${CXXSTD}` toCXXFLAGS, by only doing so when the value is specified, as opposed tooverriding the standard set by an end-user. This avoids the need for havingto bake NOP default into bsd.sys.mk for supported compiler-toolchainversions.In order to make this change possible, add CXXSTD to Makefile snippets whichrelied on the default value (c++11) added in r345708.

            List of files:
            /freebsd-12.1/lib/libc++experimental/Makefile</description>
        <pubDate>Thu, 23 May 2019 00:55:28 +0000</pubDate>
        <dc:creator>Enji Cooper &lt;ngie@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>4ba319b5 - Merge clang 7.0.1 and several follow-up changes</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++experimental/Makefile#4ba319b5</link>
        <description>Merge clang 7.0.1 and several follow-up changesMFC r341825:Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ tothe upstream release_70 branch r348686 (effectively, 7.0.1 rc3).  Therelease will follow very soon, but no more functional changes areexpected.Release notes for llvm, clang and lld 7.0.0 are available here:&lt;http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html&gt;&lt;http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html&gt;&lt;http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html&gt;PR:		230240, 230355Relnotes:	yesMFC r342123:Update clang, llvm, lld, lldb, compiler-rt and libc++ version number to7.0.1 release r349250.  There were no functional changes since the 7.0.1rc3 import.PR:		230240, 230355Relnotes:	yesr343429 | emaste | 2019-01-25 15:46:13 +0100 (Fri, 25 Jan 2019) | 16 linesclang: default to DWARF 4 as of FreeBSD 13FreeBSD previously defaulted to DWARF 2 because several tools (gdb,ctfconvert, etc.) did not support later versions.  These have eitherbeen fixed or are deprecated.Note that gdb 6 still exists but has been moved out of $PATH into/usr/libexec and is intended only for use by crashinfo(8).  The kernelbuild sets the DWARF version explicitly via -gdwarf2, so this shouldhave no effect there.PR:		234887 [exp-run]Reviewed by:	markjSponsored by:	The FreeBSD FoundationDifferential Revision:	https://reviews.freebsd.org/D17930MFC r343916:Pull in r352607 from upstream llvm trunk (by Craig Topper):  [X86] Add FPSW as a Def on some FP instructions that were missing it.Pull in r353141 from upstream llvm trunk (by Craig Topper):  [X86] Connect the default fpsr and dirflag clobbers in inline  assembly to the registers we have defined for them.  Summary:  We don&apos;t currently map these constraints to physical register numbers  so they don&apos;t make it to the MachineIR representation of inline  assembly.  This could have problems for proper dependency tracking in the  machine schedulers though I don&apos;t have a test case that shows that.  Reviewers: rnk  Reviewed By: rnk  Subscribers: eraman, llvm-commits  Tags: #llvm  Differential Revision: https://reviews.llvm.org/D57641Pull in r353489 from upstream llvm trunk (by Craig Topper):  [X86] Add FPCW as a register and start using it as an implicit use on  floating point instructions.  Summary:  FPCW contains the rounding mode control which we manipulate to  implement fp to integer conversion by changing the roudning mode,  storing the value to the stack, and then changing the rounding mode  back. Because we didn&apos;t model FPCW and its dependency chain, other  instructions could be scheduled into the middle of the sequence.  This patch introduces the register and adds it as an implciit def of  FLDCW and implicit use of the FP binary arithmetic instructions and  store instructions. There are more instructions that need to be  updated, but this is a good start. I believe this fixes at least the  reduced test case from PR40529.  Reviewers: RKSimon, spatel, rnk, efriedma, andrew.w.kaylor  Subscribers: dim, llvm-commits  Tags: #llvm  Differential Revision: https://reviews.llvm.org/D57735These should fix a problem in clang 7.0 where it would sometimes emitlong double floating point instructions in a slightly wrong order,leading to failures in our libm tests.  In particular, the cbrt_testtest case &apos;cbrtl_powl&apos; and the trig_test test case &apos;reduction&apos;.Also bump __FreeBSD_cc_version, to be able to detect this in our testsuite.Reported by:    lwhsuPR:		234040Upstream PR:	https://bugs.llvm.org/show_bug.cgi?id=40206MFC r344056:Pull in r339734 from upstream llvm trunk (by Eli Friedman):  [ARM] Make PerformSHLSimplify add nodes to the DAG worklist correctly.  Intentionally excluding nodes from the DAGCombine worklist is likely  to lead to weird optimizations and infinite loops, so it&apos;s generally  a bad idea.  To avoid the infinite loops, fix DAGCombine to use the  isDesirableToCommuteWithShift target hook before performing the  transforms in question, and implement the target hook in the ARM  backend disable the transforms in question.  Fixes https://bugs.llvm.org/show_bug.cgi?id=38530 . (I don&apos;t have a  reduced testcase for that bug. But we should have sufficient test  coverage for PerformSHLSimplify given that we&apos;re not playing weird  tricks with the worklist. I can try to bugpoint it if necessary,  though.)  Differential Revision: https://reviews.llvm.org/D50667This should fix a possible hang when compiling sys/dev/nxge/if_nxge.c(which exists now only in the stable/11 branch) for arm.

            List of files:
            /freebsd-12.1/lib/libc++experimental/Makefile</description>
        <pubDate>Sat, 16 Feb 2019 15:43:49 +0000</pubDate>
        <dc:creator>Dimitry Andric &lt;dim@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>fc539a44 - Add PICFLAG to build libc++experimental.a, so it can be used in all</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++experimental/Makefile#fc539a44</link>
        <description>Add PICFLAG to build libc++experimental.a, so it can be used in allsituations.Noticed by:	kib

            List of files:
            /freebsd-12.1/lib/libc++experimental/Makefile</description>
        <pubDate>Sun, 21 May 2017 21:33:15 +0000</pubDate>
        <dc:creator>Dimitry Andric &lt;dim@FreeBSD.org&gt;</dc:creator>
    </item>
<item>
        <title>6930ca74 - Add libc++experimental.a for std::experimental support</title>
        <link>http://172.16.0.5:8080/history/freebsd-12.1/lib/libc++experimental/Makefile#6930ca74</link>
        <description>Add libc++experimental.a for std::experimental supportThis adds a separate library for supporting std::experimental features.It is purposefully static, and must be explicitly linked into programsusing -lc++experimental.PLEASE NOTE: there is NO WARRANTY as to any stability or continuingexistence of the features in the std::experimental parts of the C++library!Reviewed by:	edDifferential Revision: https://reviews.freebsd.org/D10840

            List of files:
            /freebsd-12.1/lib/libc++experimental/Makefile</description>
        <pubDate>Sun, 21 May 2017 17:07:12 +0000</pubDate>
        <dc:creator>Dimitry Andric &lt;dim@FreeBSD.org&gt;</dc:creator>
    </item>
</channel>
</rss>
