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

Test Clang integration #71

Open
Synthetica9 opened this issue Apr 15, 2024 · 2 comments
Open

Test Clang integration #71

Synthetica9 opened this issue Apr 15, 2024 · 2 comments

Comments

@Synthetica9
Copy link
Contributor

There is some special code to support Clang (

build_config_site =
generateConf
(with buildPackages.stdenv;
{
CC = "${cc.targetPrefix}cc";
CCC = "${cc.targetPrefix}c++";
CXX = "${cc.targetPrefix}c++";
AR = "${cc.bintools.targetPrefix}ar";
LD = "${cc.bintools.targetPrefix}ld";
RANLIB = "${cc.bintools.targetPrefix}ranlib";
ARFLAGS = "rc";
}
// optionalAttrs cc.isClang {
GNU = "NO";
CMPLR_CLASS = "clang";
});
# "host" as in Nix terminology (the machine which will run the generated code)
host_config_site =
generateConf
(with stdenv;
{
CC = "${cc.targetPrefix}cc";
CCC =
if stdenv.cc.isClang
then "${cc.targetPrefix}clang++"
else "${cc.targetPrefix}c++";
CXX =
if stdenv.cc.isClang
then "${cc.targetPrefix}clang++"
else "${cc.targetPrefix}c++";
AR = "${cc.bintools.targetPrefix}ar";
LD = "${cc.bintools.targetPrefix}ld";
RANLIB = "${cc.bintools.targetPrefix}ranlib";
ARFLAGS = "rc";
COMMANDLINE_LIBRARY = "READLINE_NCURSES";
}
// optionalAttrs cc.isClang {
GNU = "NO";
CMPLR_CLASS = "clang";
});
)

I tried exercising this by overriding stdenv to clangStdenv, but that mixes gcc and clang...

The question here is two-fold

  1. Is this still supported, or has this bit-rotted in the mean time? If this is still supported, how should I access this?
  2. Should we test this somehow? Seems prudent to at least build the epics-base package with clang if we have specific code to support this
@minijackson
Copy link
Collaborator

Is this still supported, or has this bit-rotted in the mean time? If this is still supported, how should I access this?

I tested it a while time ago, to stop clang-tidy / clangd from bothering me by trying to include the gcc-specific header files.

Should we test this somehow? Seems prudent to at least build the epics-base package with clang if we have specific code to support this

I'm in favor of testing this. What's your usecase? Is this to prepare for macOS support?

I've managed to build epics-base with clang in the REPL like this:

pkgs = import <nixpkgs> { overlays = [epnix.overlays.default]; }
pkgs.epnix.epics-base.override {
  stdenv = pkgs.clangStdenv;
  buildPackages = pkgs.buildPackages // { stdenv = pkgs.buildPackages.clangStdenv; };
  mkEpicsPackage = pkgs.mkEpicsPackage.override {
    stdenv = pkgs.clangStdenv;
    buildPackages = pkgs.buildPackages // { stdenv = pkgs.buildPackages.clangStdenv; };
  };
}

It's way too convoluted for my taste. Here's what I think could make it simpler:

  • retire mkEpicsPackage and use setup hooks instead
  • see if we it's possible to use package splicing instead of buildPackages, so we don't need to specify clangStdenv twice.

@Synthetica9
Copy link
Contributor Author

What's your usecase? Is this to prepare for macOS support?

I had no specific use-case, I wanted to try a different compiler to diagnose the hardening issue in solved in #67, but maybe OpenBSD down the line. I just ran into the Clang-specific code that was not exercised anywhere

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

No branches or pull requests

2 participants