Add net-snmp/5.9.1

[friendlyanon]

Specify library name and version: net-snmp/5.9.1

Issue: #8618

---

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the
  conan-center hook activated.

[Croydon]

@jgsogo Is this potentially a bug in the Epochs feature? IIUC this PR should not run GCC 11 builds if the deps aren't there

[SSE4]

@jgsogo Is this potentially a bug in the Epochs feature? IIUC this PR should not run GCC 11 builds if the deps aren't there

yes, clearly, something is wrong with epoch computation here, and in few other PRs

[danimtb]

We deployed a fix for this. It is working now!

[friendlyanon]

I have no means to test/reproduce/investigate this error locally. cc @SpaceIm since it's an error on MacOS

[jgsogo]

I think this is the same error that is fixed in some other recipes adding a build_requires to the test-package recipe:

    def build_requirements(self):
        if self.settings.os == "Macos" and self.settings.arch == "armv8":
            # Attempting to use @rpath without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG being
            # set. This could be because you are using a Mac OS X version less than 10.5
            # or because CMake's platform configuration is corrupt.
            self.build_requires("cmake/3.20.1")

[friendlyanon]

It seems that this is related to CMP0068, which was added in 3.9. Simply changing the minimum requirement of the test package to cmake_minimum_required(VERSION 3.9) would ensure that this policy is active in tests. That build requirement still wouldn't activate this policy.

However, I'm not sure this is the proper solution. CMake built libraries do not need anything like this. Maybe something in the build scripts of this project should be done to fix up installed binaries.

[SpaceIm]

@friendlyanon I don't think it's related to CMP0068, but you can try. For sure, @jgsogo suggestion will fix this issue in test package for macOS M1, it has been tested in many recipes.

[friendlyanon]

So, the problem was that CMake doesn't even support macOS on ARM before 3.19.2 and even then, this bug in particular was fixed in the 3.20.1 release. This problem didn't manifest itself for me before, because apparently dependencies disabled this particular configuration in other recipes I submitted.

[SpaceIm]

Yes. As mentioned by @SSE4 in another PR, maybe macOS M1 agent in CI should have CMake >= 3.20.1 by default.

[friendlyanon]

That was the conclusion in Slack as well :)

[SpaceIm]

why settings_build here?

[friendlyanon]

I'm not sure actually. I believe I may have copy-pasted this from somewhere without much thought.

[SpaceIm]

pretty sure you want self.settings.compiler here

[friendlyanon]

Before I push a fix, where can I read about the significance of settings_build and where it should be used? Also, is it used properly in validate()?

[SpaceIm]

settings refers to settings of host profile (target), and settings_build to settings of build profile (stuff coming from build requirements and logic related to build machine).

Also, is it used properly in validate()?

Maybe, maybe not.
Can it be cross-built from windows to another OS with another compiler than msvc, from linux to Windows with minGW?

[friendlyanon]

Can it be cross-built from windows to another OS with another compiler than msvc, from linux to Windows with minGW?

Provided that the _build_unix() method is invoked, I don't believe there is anything preventing this from being cross-compiled on Windows.

[SpaceIm]

So it means that MinGW should work, and there is no reason to prevent Windows build with MinGW on Windows.

[conan-center-bot]

All green in build 2 (95c8d2d876333314b4beda80879779c8da437e7c):

• net-snmp/5.9.1@:
  All packages built successfully! (All logs)