improve ignore_run_exports, don't refer to -ng packages

[conda-forge-admin]

Xref conda-forge/ctng-compilers-feedstock#148

Fixes #17

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.

Here's what I've got...

For recipe/meta.yaml:

• This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[h-vetinari]

PPC is going to fail on travis conda-forge/status#185; we could change this to cross-compilation, but given that the content of the package is essentially only CMake metadata, we could also just make this noarch: generic and just build it once? Thoughts @conda-forge/ldas-tools-cmake?

[duncanmmacleod]

PPC is going to fail on travis conda-forge/status#185; we could change this to cross-compilation, but given that the content of the package is essentially only CMake metadata, we could also just make this noarch: generic and just build it once? Thoughts @conda-forge/ldas-tools-cmake?

@h-vetinari, I have made this noarch: generic but with separate builds for unix and Windows because the Windows files go into <prefix>\Library\; is that the best thing to do here?

[h-vetinari]

I have made this noarch: generic but with separate builds for unix and Windows because the Windows files go into <prefix>\Library\; is that the best thing to do here?

That's a great point, and is exactly the right way to fix this IMO. 👍 from me.