Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings
/perl5Public

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

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
tonycoz merged 2 commits intoPerl:bleadfromtonycoz:c++-header-porting
Jul 23, 2024

Conversation

tonycoz
Copy link
Contributor

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 probewith 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.

@tonycoztonycoz added the defer-next-devThis PR should not be merged yet, but await the next development cycle labelMay 22, 2024
@jkeenanjkeenan removed the defer-next-devThis PR should not be merged yet, but await the next development cycle labelJun 10, 2024
@jkeenan
Copy link
Contributor

  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.

@jkeenan
Copy link
Contributor

  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.

    1. 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.

Is there anyone familiar enough with C++ headers to give this proposal for a porting test a review?

IMO it's the sort of thing that, if we're going to pull it into core, we should do so now, at an early point in the current development cycle.

Adding _GNU_SOURCE, which was done much later, should give us theGNU-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, andchecks that compiler for any options controlling the C++ standardrequested, including simple checks that the compiler supports thatstandard.If a C++ compiler is found, test compilation of the same simple codeas above but with the perl headers included after any C++ headers.Ideally we'd also test runtime, but would require more complex testcode, 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 perlccflags, since icc (Intel classic) would successfully build the samplewithout perl's ccflags, but then fail with both the headers and perl'sccflags.  It turned out to fail with just the ccflags, and since theprimary intent is to test the headers, I probe *with* ccflags.The Sun Workshop compiler failed to build the C++11 or 14 sample atall in my testing, which may have been due to an installation problem.
@tonycoz
Copy link
ContributorAuthor

Fixed everything I think:

  • added a comma
  • removed a'
  • switched to$cc
  • removed duplicate diagnostic output on the initial detection
  • used\Q$exe\E where I was using.exe
  • cleaned up the MSVC regexp

@tonycoztonycoz merged commitde5c773 intoPerl:bleadJul 23, 2024
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@maukemaukemauke approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

3 participants
@tonycoz@jkeenan@mauke
[8]ページ先頭
©2009-2025 Movatter.jp