Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

porting/cpphdrcheck.t: test perl's headers with C++ compilers #22232

Open
wants to merge 2 commits into
base: blead
Choose a base branch
from

Conversation

tonycoz
Copy link
Contributor

@tonycoz tonycoz commented May 22, 2024

This searches for a C++ compiler based on the supplied C compiler, and
checks that compiler for any options controlling the C++ standard
requested, including simple checks that the compiler supports that
standard.

If a C++ compiler is found, test compilation of the same simple code
as above but with the perl headers included after any C++ headers.

Ideally we'd also test runtime, but would require more complex test
code, which I leave to later contributors (which may still be me).

Tested at various times with:

  • MSVC
  • gcc
  • clang
  • Oracle/Sun Development Workshop cc (CC is the C++ compiler), on Oracle Linux
  • Intel oneAPI compiler (llvm based apparently, and now free to use)
  • Intel classic compiler (discontinued)

Currently this probes the compiler for C++ sanity with the perl
ccflags, since icc (Intel classic) would successfully build the sample
without perl's ccflags, but then fail with both the headers and perl's
ccflags. It turned out to fail with just the ccflags, and since the
primary intent is to test the headers, I probe with ccflags.

The Sun Workshop compiler failed to build the C++11 or 14 sample at
all in my testing, which may have been due to an installation problem.

This branch also removes an option added to ccflags by the cygwin hints
that prevented C++ code from compiling.

Adding _GNU_SOURCE, which was done much later, should give us the
GNU-ish symbols (though POSIX_C_SOURCE would be more general.)

I couldn't find the reason for this being added, but the C++
headers react badly to it:

In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iostream:38,
                 from source.cpp:1:
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/c++config.h:573:2: warning: #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" [-Wcpp]
  573 | #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported"
      |  ^~~~~~~
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/max_size_type.h:37,
                 from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ranges_base.h:38,
                 from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/string_view:48,
                 from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/basic_string.h:48,
                 from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/string:55,
                 from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/locale_classes.h:40,
                 from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:41,
                 from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ios:42,
                 from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ostream:38,
                 from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iostream:39,
                 from source.cpp:1:
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/numbers:139:9: error: unable to find numeric literal operator 'operator""Q'
  139 |       = 2.718281828459045235360287471352662498Q;
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
This searches for a C++ compiler based on the supplied C compiler, and
checks that compiler for any options controlling the C++ standard
requested, including simple checks that the compiler supports that
standard.

If a C++ compiler is found, test compilation of the same simple code
as above but with the perl headers included after any C++ headers.

Ideally we'd also test runtime, but would require more complex test
code, which I leave to later contributors (which may still be me).

Tested at various times with:

 - MSVC
 - gcc
 - clang
 - Oracle/Sun Development Workshop cc (CC is the C++ compiler), on
   Oracle Linux
 - Intel oneAPI compiler (llvm based apparently, and now free to use)
 - Intel classic compiler (discontinued)

Currently this probes the compiler for C++ sanity with the perl
ccflags, since icc (Intel classic) would successfully build the sample
without perl's ccflags, but then fail with both the headers and perl's
ccflags.  It turned out to fail with just the ccflags, and since the
primary intent is to test the headers, I probe *with* ccflags.

The Sun Workshop compiler failed to build the C++11 or 14 sample at
all in my testing, which may have been due to an installation problem.
@tonycoz tonycoz added the defer-next-dev This PR should not be merged yet, but await the next development cycle label May 22, 2024
@jkeenan jkeenan removed the defer-next-dev This PR should not be merged yet, but await the next development cycle label Jun 10, 2024
@jkeenan
Copy link
Contributor

jkeenan commented Jun 10, 2024

  1. I fetched this pull request today, rebased it on (post-perl-5.40.0) blead and compiled and tested it on FreeBSD-13 with both gcc+12 and clang++14. All tests PASSed.
  2. Several weeks ago I forked a 'smoke-me' branch from this pull request. It did very well on two smoke-testing rigs (http://perl.develop-help.com/?b=smoke-me%2Ftonyc%2Fcpp-header-porting) -- but I think the p.r. should still get some eyeballs from people who know more about C++ and headers than I do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants