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

Add LoopTools #28292

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

matthewfeickert
Copy link
Member

@matthewfeickert matthewfeickert commented Nov 20, 2024

Checklist

  • Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
  • License file is packaged (see here for an example).
  • Source is from official source.
  • Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
  • If static libraries are linked in, the license of the static library is packaged.
  • Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
  • Build number is 0.
  • A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
  • GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
  • When in trouble, please check our knowledge base documentation before pinging a team.

Copy link

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

@conda-forge-admin
Copy link
Contributor

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 (recipes/looptools/meta.yaml) and found it was in an excellent condition.

@matthewfeickert matthewfeickert force-pushed the feat/add-LoopTools branch 5 times, most recently from 829c78d to fa84830 Compare November 20, 2024 22:05
@conda-forge-admin
Copy link
Contributor

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 (recipes/looptools/meta.yaml) and found some lint.

Here's what I've got...

For recipes/looptools/meta.yaml:

  • ❌ The recipe must have a build/number section.

@conda-forge-admin
Copy link
Contributor

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 (recipes/looptools/meta.yaml) and found it was in an excellent condition.

@matthewfeickert matthewfeickert marked this pull request as ready for review November 21, 2024 07:54
Copy link
Member Author

@matthewfeickert matthewfeickert left a comment

Choose a reason for hiding this comment

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

For reviewers:

  • Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).

LoopTools vendors a significantly modified version of FF (c.f. hep-packaging-coordination/packaging-hep-simulation-stack#4 (comment)). FF is unlicensed Fortran code from 1998 and the original author has died. c.f. hep-packaging-coordination/packaging-hep-simulation-stack#4

  • If static libraries are linked in, the license of the static library is packaged.

FF is statically linked into libooptools.a. As FF is unlicensed code (c.f. above) there is no additional license to include beyond LoopTools's GPL-3.0-only.

  • Package does not ship static libraries. If static libraries are needed, follow CFEP-18.

LoopTools only supports static linking at the moment given the author's decision to remove it. c.f. hep-packaging-coordination/packaging-hep-simulation-stack#4 (comment)

cc @t-hahn (LoopTools author) in the event they have any comments or corrections.

@matthewfeickert
Copy link
Member Author

@conda-forge/staged-recipes, ready for review! This is a fortran recipe.

Copy link

To help direct your pull request to the best reviewers, please mention a topic-specifc team if your recipe matches any of the following: conda-forge/help-c-cpp, conda-forge/help-cdts, conda-forge/help-go, conda-forge/help-java, conda-forge/help-julia, conda-forge/help-nodejs, conda-forge/help-perl, conda-forge/help-python, conda-forge/help-python-c, conda-forge/help-r, conda-forge/help-ruby,or conda-forge/help-rust. Thanks!

# c.f. https://github.com/hep-packaging-coordination/packaging-hep-simulation-stack/issues/4#issuecomment-2489198926
# - ./configure --prefix=$PREFIX --dynamic --64 --native
- ./configure --prefix=$PREFIX --64 # [build_platform != target_platform]
- ./configure --prefix=$PREFIX --64 --native # [build_platform == target_platform]
Copy link
Member Author

Choose a reason for hiding this comment

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

Suggested change
- ./configure --prefix=$PREFIX --64 --native # [build_platform == target_platform]
- ./configure --prefix=$PREFIX --64 --native # [build_platform == target_platform]

Reviewers, is setting -march=native here safe to do for a CI job? Or should this only ever be done when you're building on the same machine you plan to run on?

Copy link
Member

Choose a reason for hiding this comment

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

Never ever set --native if you want to use the binary on multiple system. Please use the provided C(XX)FLAGS from the compiler activation scripts.

build:
skip: true # [win]
run_exports:
- {{ pin_subpackage('looptools-static', max_pin='x.x') }}
Copy link
Member

Choose a reason for hiding this comment

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

If it is static, it should need a run_exports.

Copy link
Member Author

Choose a reason for hiding this comment

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

@xhochy Hm, I thought from https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#export-runtime-requirements that I was setting run_exports here. Is there more clear documentation on how this works?

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Hm, or should the run_exports be at the top level instead?

diff --git a/recipes/looptools/meta.yaml b/recipes/looptools/meta.yaml
index d9c5496de2..cd8b8240aa 100644
--- a/recipes/looptools/meta.yaml
+++ b/recipes/looptools/meta.yaml
@@ -11,14 +11,14 @@ source:
 
 build:
   number: 0
+  run_exports:
+    - {{ pin_subpackage('looptools-static', max_pin='x.x') }}
 
 outputs:
   - name: {{ name }}-static
 
     build:
       skip: true  # [win]
-      run_exports:
-        - {{ pin_subpackage('looptools-static', max_pin='x.x') }}
       ignore_run_exports_from:
         - {{ compiler('cxx') }}
       script:

- ./configure --prefix=$PREFIX --64 --native # [build_platform == target_platform]
- make
- make install
- ln -s -f $PREFIX/lib64/libooptools.a $PREFIX/lib/libooptools.a # [linux]
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
- ln -s -f $PREFIX/lib64/libooptools.a $PREFIX/lib/libooptools.a # [linux]
- mv $PREFIX/lib64/libooptools.a $PREFIX/lib/libooptools.a # [linux]

Copy link
Member Author

Choose a reason for hiding this comment

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

@xhochy The motivation here for this change is that conda doesn't distinguish between $CONDA_PREFIX/lib and $CONDA_PREFIX/lib64 (i.e. there is no $CONDA_PREFIX/lib64), and so having one package with a subdir like this isn't useful? Or is there another reason?

recipes/looptools/meta.yaml Outdated Show resolved Hide resolved
Copy link
Member Author

@matthewfeickert matthewfeickert left a comment

Choose a reason for hiding this comment

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

Thanks @xhochy. I'll push changes, but I also have some questions.

build:
skip: true # [win]
run_exports:
- {{ pin_subpackage('looptools-static', max_pin='x.x') }}
Copy link
Member Author

Choose a reason for hiding this comment

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

@xhochy Hm, I thought from https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#export-runtime-requirements that I was setting run_exports here. Is there more clear documentation on how this works?

- ./configure --prefix=$PREFIX --64 --native # [build_platform == target_platform]
- make
- make install
- ln -s -f $PREFIX/lib64/libooptools.a $PREFIX/lib/libooptools.a # [linux]
Copy link
Member Author

Choose a reason for hiding this comment

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

@xhochy The motivation here for this change is that conda doesn't distinguish between $CONDA_PREFIX/lib and $CONDA_PREFIX/lib64 (i.e. there is no $CONDA_PREFIX/lib64), and so having one package with a subdir like this isn't useful? Or is there another reason?

* Add LoopTools v2.16.
   - c.f. https://feynarts.de/looptools/
* Looptools currently only supports static linking, so following CFEP-18,
  create 'looptools-static' output.
   - c.f. https://github.com/conda-forge/cfep/blob/main/cfep-18.md
# FIXME: Author has disabled builds with dynamic linking
# c.f. https://github.com/hep-packaging-coordination/packaging-hep-simulation-stack/issues/4#issuecomment-2489198926
# - ./configure --prefix=$PREFIX --dynamic --64 $CXXFLAGS
- ./configure --prefix=$PREFIX --64 $CXXFLAGS
Copy link
Member Author

Choose a reason for hiding this comment

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

I've added $CXXFLAGS but kept the --64. I presume that's okay, though if that's something that's discouraged I can check to see how much LoopTools uses this --64 information.

@matthewfeickert
Copy link
Member Author

@xhochy general question. As this is Fortran I've not been selecting a language team and just been mentining in my review request comment (#28292 (comment)) that the recipe is fortran . Do you have suggestions on how I can better communicate and label these sorts of PRs for the reviewers?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants