Thanks! While changing the definitions to $(CXX) did not work and resulted
in:
Running test_stack.R.................. 0 tests
/usr/lib/R/etc/Makevars.site:5: *** Recursive variable 'CXX' references
itself (eventually). Stop.
It did make me just say "be verbose", so I explicitly set each CXXNN
variable to clang++ as well as stating each one's explicit CXXNNSTD to be
the appropriate -std=c++NN and the result is:
[1] "All ok, 1541 results"
Woohoo! All tests using clang and gcc on WSL :thumbsup:
On Tue, Jun 16, 2020 at 2:55 PM William Dunlap <wdun...@tibco.com> wrote:
> Your Makevar.site is incorrect. Replace
> CXX11 = $CXX
> with
> CXX11 = $(CXX)
>
> $CXX only expands the macro 'C', not 'CXX'. Since C is not defined $CXX
> expands to XX.
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Tue, Jun 16, 2020 at 12:39 PM Thell Fowler <tbfowl...@gmail.com> wrote:
>
>> Windows 10 Pro 2004 19041.329
>> WSL Version 2
>> Linux DESKTOP-K8EN726 4.19.104-microsoft-standard #1 SMP Wed Feb 19
>> 06:37:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Distributor ID: Ubuntu
>> Description: Ubuntu 20.04 LTS
>> Release: 20.04
>> Codename: focal
>>
>> Sys.setenv("RunAllRcppTests"="yes")
>> Sys.setenv("RunVerboseRcppTests"="yes")
>> tinytest::test_package("Rcpp")
>>
>> -------------------------------------------
>>
>> using: gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
>> *[1] "All ok, 1541 results"*
>>
>> -------------------------------------------
>>
>> using: Ubuntu clang version
>> 10.0.1-++20200529022935+a634a80615b-1~exp1~20200529003545.39
>> with Makevars.site containing:
>>
>> CC = clang
>> CXX = clang++
>> CFLAGS = -g -O2
>> CXXFLAGS = -g -O2
>> CXX11 = $CXX
>> CXX14 = $CXX
>> CXX17 = $CXX
>> CXX20 = $CXX
>> CXX1X = $CXX
>>
>>
>> Halted with:
>> Running test_stack.R.................. 0 tests /bin/bash: XX:
>> command not found
>> make: *** [/usr/lib/R/etc/Makeconf:176: stack.o] Error 127
>> XX -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG
>> -DRCPP_USE_UNWIND_PROTECT -I"/usr/local/lib/R/site-library/Rcpp/include"
>> -I"/usr/local/lib/R/site-library/Rcpp/tinytest/cpp" -fpic -g -O2
>> -fdebug-prefix-map=/build/r-base-Do_dS_/r-base-4.0.0=.
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
>> -D_FORTIFY_SOURCE=2 -g -c stack.cpp -o stack.o
>> Error in Rcpp::sourceCpp("cpp/stack.cpp") :
>> Error 1 occurred building shared library.
>>
>> I'm fairly sure the issue is on my setup but not quite sure what it is
>> from a quick glance.
>>
>> -------------------------------------------
>> > R.version
>> platform x86_64-pc-linux-gnu
>> arch x86_64
>> os linux-gnu
>> system x86_64, linux-gnu
>> status
>> major 4
>> minor 0.0
>> year 2020
>> month 04
>> day 24
>> svn rev 78286
>> language R
>> version.string R version 4.0.0 (2020-04-24)
>> nickname Arbor Day
>>
>>
>> On Tue, Jun 16, 2020 at 8:47 AM Dirk Eddelbuettel <e...@debian.org> wrote:
>>
>>>
>>> Hi all,
>>>
>>> Below is an ascii version of what I blogged yesterday, proper URL links
>>> are
>>> at http://dirk.eddelbuettel.com/blog/2020/06/15#rcpp_1.0.5_testing
>>>
>>> Help in testing, particular on unusual hardware or compiler choices, or
>>> particularly old releases of OS, compiler, R, ... would be welcome. I am
>>> quite confident the release will be fine on CRAN and standard systems.
>>>
>>> But for use on less standard setups, the time to test is now. If you are
>>> a
>>> user of Rcpp under such circumstance, please help now in testing and
>>> reporting issues, if any are seen.
>>>
>>> Thanks, Dirk
>>>
>>>
>>> Mon, 15 Jun 2020
>>>
>>> Rcpp 1.0.5 in two+ weeks: Please help test
>>>
>>> rcpp logo
>>>
>>> With the current four-month release cycle, the next Rcpp release is
>>> due in
>>> July following the 1.0.4 release in March. Just prior to the 1.0.4
>>> release
>>> I had asked this:
>>>
>>> It would be particularly beneficial if those with “unsual” build
>>> dependencies tested it as we would increase overall coverage beyond
>>> what
>>> I get from testing against 1800+ CRAN packages. BioConductor would
>>> also
>>> be welcome.
>>>
>>> but only on the rcpp-devel list, and only about a good week prior to
>>> the
>>> release.
>>>
>>> I remain rather disappointed and disillusioned about what happened
>>> after
>>> 1.0.4 was released. Two PRs in that release were soon seen to have
>>> side
>>> effects on more ‘marginal’ test systems, precisely what added testing
>>> could have revealed. An additional issue arose from changes in R’s
>>> make
>>> system, which is harder to anticipate or test. Each and every
>>> infelicity
>>> was fixed within a day or so, and we always make candidate releases
>>> available—the current Rcpp as of this writing is 1.0.4.12 meaning
>>> twelve
>>> microreleases were made since 1.0.4. And those microreleases are
>>> always
>>> available for normal download and install.packages use via the Rcpp
>>> drat
>>> repository accessible to all. So it was truly troubling to see some,
>>> especially those with experience in setting up or running testing / ci
>>> platforms, pretend to be unable to access, install, and provide these
>>> for
>>> their own tests, or the tests of their users. It just doesn’t pass a
>>> basic
>>> logic test: it takes a single call to install.packages(), or, even
>>> more
>>> easily, a single assignment of an auxiliary repo. All told this was a
>>> rather sad experience.
>>>
>>> So let’s try to not repeat this. If you, or maybe users of a build or
>>> ci
>>> system you maintain, rely on Rcpp, and especially if you do so on
>>> systems
>>> outside the standard CRAN grid of three OSs and the triplet of
>>> “previous,
>>> current, next” releases of R, then please help by testing. I maitain
>>> these
>>> release as a volunteer, unpaid at that, and I simply cannot expand to
>>> more
>>> systesm. We take reverse dependency check seriously (and I just run
>>> two
>>> taking about a day each) but if you insist on building on stranger
>>> hardware or much older releases it will be up to you to ensure Rcpp
>>> passes. We prep for CRAN, and try our best to pass at CRAN. For
>>> nearly a
>>> dozen years.
>>>
>>> To install the current microrelease from the Rcpp drat repository,
>>> just do
>>>
>>> install.packages("Rcpp", repos="https://rcppcore.github.io/drat";)
>>>
>>> That is all there is to it. You could even add the Rcpp drat
>>> repository to
>>> your repository list.
>>>
>>> Rcpp has become successful because so many people help with
>>> suggestions,
>>> documentation, and code. It is used by (as of today) 1958 CRAN
>>> packages,
>>> 205 BioConductor packages, and downloaded around a million times per
>>> month. So if you can, please help now with some more testing.
>>>
>>> If you like this or other open-source work I do, you can now sponsor
>>> me at
>>> GitHub. For the first year, GitHub will match your contributions.
>>>
>>> This post by Dirk Eddelbuettel originated on his Thinking inside the
>>> box
>>> blog. Please report excessive re-aggregation in third-party for-profit
>>> settings.
>>>
>>> /code/rcpp | permanent
>>> link
>>>
>>>
>>>
>>> --
>>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>>> _______________________________________________
>>> Rcpp-devel mailing list
>>> Rcpp-devel@lists.r-forge.r-project.org
>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>>
>>
>>
>> --
>> Sincerely,
>> Thell
>> _______________________________________________
>> Rcpp-devel mailing list
>> Rcpp-devel@lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
>
--
Sincerely,
Thell
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
