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

haproxy: PCRE and LUA support as configurable options #24248

Closed
wants to merge 2 commits into from

Conversation

fuzzy-id
Copy link
Contributor

Motivation for this change

This solves #23806 and is a follow up to #23901. PCRE and LUA support are added via configurable options. Both are enabled by default, apart from LUA on Darwin where compilation breaks.

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

Thomas Bach added 2 commits March 23, 2017 21:16
`preConfigure` line became too long to edit comfortably. Split up
flags into ones necessary during both build and install phase and
install phase only. Makefile defines a target for OS X/Darwin which
automatically sets the `KQUEUE` flag.
PCRE is enabled by default as it brings. LUA support does not compile on
Darwin (see NixOS#23901). Hence, it is disabled on this platform by default.
@mention-bot
Copy link

@fuzzy-id, thanks for your PR! By analyzing the history of the files in this pull request, we identified @rbvermaa, @pmahoney and @garbas to be potential reviewers.

haproxy = callPackage ../tools/networking/haproxy { };
haproxy = callPackage ../tools/networking/haproxy {
useLua = if stdenv.isDarwin then false else true;
lua = if stdenv.isDarwin then null else lua5_3;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the conditional is not needed here

@@ -1,4 +1,8 @@
{ stdenv, pkgs, fetchurl, openssl, zlib }:
{ useLua ? false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using !stdenv.isDarwin here is a bit nicer then doing it top level.

Copy link
Contributor Author

@fuzzy-id fuzzy-id Mar 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, I haven't thought that this would be possible. But I haven't read up on scoping in nix.
So this would result into a function header looking like this:

{ useLua ? !stdenv.isDarwin
, usePcre ? true
, stdenv, fetchurl
, openssl, zlib, lua5_3 ? null, pcre ? null
}:
# …

lua5_3 ? null and pcre ? null look a bit strange to me but it compiles alright.

Is there anything additionally to do, to avoid recompilation when e.g. pcre changes although usePcre = false?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing will rebuild if pcre is not used in the derivation when usePcre is disabled. Adding a default for the optional packages is not strictly necessary but it makes it easier to import the file directly, another thing that's usually added in this case is an assert to make sure the package exists when the use option is enabled.

{ stdenv, openssl, zlib
, usePcre ? true, pcre ? null
, useLua ? !stdenv.isDarwin, lua ? null
}:

assert usePcre -> pcre != null;
assert useLua -> lua != null;
# ...

@fuzzy-id
Copy link
Contributor Author

Closed in favour of #24380.

@fuzzy-id fuzzy-id closed this Mar 27, 2017
@Mic92
Copy link
Member

Mic92 commented Mar 27, 2017

Can you do a git push --force the next time instead of a new pull request? Otherwise older reviews get lost.

@fuzzy-id
Copy link
Contributor Author

Sorry for the noise. I haven't known this option before.

@fuzzy-id fuzzy-id deleted the haproxy-overworked branch March 31, 2017 13:22
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

4 participants