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

winnowmap & meryl: add aarch64/arm64 builds #51162

Closed
wants to merge 1 commit into from

Conversation

martin-g
Copy link
Contributor

@martin-g martin-g commented Oct 4, 2024

Describe your pull request here


Please read the guidelines for Bioconda recipes before opening a pull request (PR).

General instructions

  • If this PR adds or updates a recipe, use "Add" or "Update" appropriately as the first word in its title.
  • New recipes not directly relevant to the biological sciences need to be submitted to the conda-forge channel instead of Bioconda.
  • PRs require reviews prior to being merged. Once your PR is passing tests and ready to be merged, please issue the @BiocondaBot please add label command.
  • Please post questions on Gitter or ping @bioconda/core in a comment.

Instructions for avoiding API, ABI, and CLI breakage issues

Conda is able to record and lock (a.k.a. pin) dependency versions used at build time of other recipes.
This way, one can avoid that expectations of a downstream recipe with regards to API, ABI, or CLI are violated by later changes in the recipe.
If not already present in the meta.yaml, make sure to specify run_exports (see here for the rationale and comprehensive explanation).
Add a run_exports section like this:

build:
  run_exports:
    - ...

with ... being one of:

Case run_exports statement
semantic versioning {{ pin_subpackage("myrecipe", max_pin="x") }}
semantic versioning (0.x.x) {{ pin_subpackage("myrecipe", max_pin="x.x") }}
known breakage in minor versions {{ pin_subpackage("myrecipe", max_pin="x.x") }} (in such a case, please add a note that shortly mentions your evidence for that)
known breakage in patch versions {{ pin_subpackage("myrecipe", max_pin="x.x.x") }} (in such a case, please add a note that shortly mentions your evidence for that)
calendar versioning {{ pin_subpackage("myrecipe", max_pin=None) }}

while replacing "myrecipe" with either name if a name|lower variable is defined in your recipe or with the lowercase name of the package in quotes.

Bot commands for PR management

Please use the following BiocondaBot commands:

Everyone has access to the following BiocondaBot commands, which can be given in a comment:

@BiocondaBot please update Merge the master branch into a PR.
@BiocondaBot please add label Add the please review & merge label.
@BiocondaBot please fetch artifacts Post links to CI-built packages/containers.
You can use this to test packages locally.

Note that the @BiocondaBot please merge command is now depreciated. Please just squash and merge instead.

Also, the bot watches for comments from non-members that include @bioconda/<team> and will automatically re-post them to notify the addressed <team>.

Summary by CodeRabbit

  • New Features

    • Enhanced build scripts for improved execution behavior and parallel job processing.
    • Added support for new platforms in the meryl package.
  • Updates

    • Incremented build numbers for both meryl and winnowmap packages.
    • Updated version specifications in the winnowmap package to reflect recent changes.
  • Bug Fixes

    • Corrected indentation issues in the meta.yaml files for better structure and readability.

@martin-g martin-g added aarch64 Related to adding linux-aarch64 support osx-arm64 Related to adding osx-arm64 support labels Oct 4, 2024
Copy link
Contributor

coderabbitai bot commented Oct 4, 2024

📝 Walkthrough

Walkthrough

The pull request introduces modifications to the build.sh scripts for both the meryl and winnowmap packages, enhancing their execution behavior by adding the set -xe command and enabling parallel execution with make -j ${CPU_COUNT}. Additionally, the meta.yaml files for both packages are updated: the meryl package sees an increment in its build number and the addition of new platforms, while the winnowmap package updates its version and build number, adds a new run_exports section, and adjusts requirements.

Changes

File Path Change Summary
recipes/meryl/build.sh Added set -xe for error handling and command printing; updated make command to include -j ${CPU_COUNT}.
recipes/meryl/meta.yaml Incremented build number from 0 to 1; added platforms linux-aarch64 and osx-arm64; corrected indentation.
recipes/winnowmap/build.sh Added set -xe for error handling and command printing; updated make command to include -j ${CPU_COUNT}.
recipes/winnowmap/meta.yaml Updated version to 2.03, incremented build number from 2 to 3; added run_exports section; noted meryl updates.

Possibly related PRs

Suggested labels

please review & merge

Suggested reviewers

  • mencian
  • bgruening

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Signed-off-by: Martin Tzvetanov Grigorov <[email protected]>
@martin-g martin-g force-pushed the aarch64-winnowmap-meryl branch from 85720c4 to eb84f89 Compare October 4, 2024 12:25
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (2)
recipes/meryl/build.sh (2)

Line range hint 5-10: Good optimization with parallel compilation

The addition of -j ${CPU_COUNT} to the make command is an excellent optimization. This allows the build process to utilize multiple CPU cores, potentially significantly reducing build times. The use of ${CPU_COUNT} is particularly good as it automatically adapts to the available resources on the build machine.

However, I noticed that -j${CPU_COUNT} is repeated at the end of the command. This is redundant and might cause confusion.

Consider removing the redundant -j"${CPU_COUNT}" at the end of the line. Here's the suggested change:

 make -C src -j ${CPU_COUNT} BUILD_DIR="$(pwd)" \
 	TARGET_DIR="${PREFIX}" \
 	CXX="${CXX}" \
 	CXXFLAGS="${CXXFLAGS} -O3 -I${PREFIX}/include" \
-	LDFLAGS="${LDFLAGS} -fopenmp -L${PREFIX}/lib" -j"${CPU_COUNT}"
+	LDFLAGS="${LDFLAGS} -fopenmp -L${PREFIX}/lib"

Line range hint 5-10: LGTM: Existing build configuration looks good

The unchanged parts of the build script follow good practices:

  1. Using Conda environment variables (${PREFIX}, ${CXX}, etc.) ensures compatibility with the Conda build system.
  2. Setting custom CXXFLAGS with -O3 enables high-level optimizations.
  3. Including -fopenmp in LDFLAGS suggests proper support for parallel processing with OpenMP.
  4. Correctly setting BUILD_DIR and TARGET_DIR ensures proper file locations.

One minor suggestion for improved readability:

Consider breaking the long make command into multiple lines for better readability. Here's an example:

make -C src -j ${CPU_COUNT} \
    BUILD_DIR="$(pwd)" \
    TARGET_DIR="${PREFIX}" \
    CXX="${CXX}" \
    CXXFLAGS="${CXXFLAGS} -O3 -I${PREFIX}/include" \
    LDFLAGS="${LDFLAGS} -fopenmp -L${PREFIX}/lib"

This change doesn't affect functionality but makes the script easier to read and maintain.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 625280e and eb84f89.

📒 Files selected for processing (4)
  • recipes/meryl/build.sh (1 hunks)
  • recipes/meryl/meta.yaml (2 hunks)
  • recipes/winnowmap/build.sh (1 hunks)
  • recipes/winnowmap/meta.yaml (1 hunks)
🔇 Additional comments (11)
recipes/meryl/build.sh (1)

3-4: Excellent addition of set -xe

The addition of set -xe is a great improvement to the build script. This command does two things:

  1. -e: Exits the script immediately if any command fails, which helps prevent cascading errors.
  2. -x: Prints each command before executing it, which aids in debugging by showing exactly what commands are being run.

These options enhance the script's robustness and make it easier to troubleshoot if issues arise during the build process.

recipes/winnowmap/build.sh (4)

3-3: Excellent addition of set -xe for improved build reliability and debugging.

The addition of set -xe enhances the build process in two ways:

  1. It ensures the build stops immediately if any command fails (-e), preventing potential issues from silent failures.
  2. It enables verbose mode (-x), printing each command before execution, which is invaluable for debugging.

These improvements are particularly beneficial when adding new architecture builds like aarch64/arm64, as they can help quickly identify and debug any platform-specific issues.


5-5: Great optimization with parallel compilation using -j ${CPU_COUNT}.

The addition of -j ${CPU_COUNT} to the make command enables parallel compilation, which can significantly speed up the build process. This is particularly beneficial when building for new architectures like aarch64/arm64, as it optimizes the build for the specific machine it's running on.


5-5: Verify architecture-specific compilation flags for aarch64/arm64.

While the existing CPPFLAGS seem to be maintained, it's important to verify if any additional architecture-specific flags are required for optimal compilation on aarch64/arm64 platforms.

Could you please confirm if any aarch64/arm64-specific compilation flags need to be added to the CPPFLAGS? This will ensure optimal performance and compatibility on the new architecture.


Line range hint 1-10: Inquiry about meryl package build.

The PR objectives mention adding builds for both winnowmap and meryl packages. While this script addresses the winnowmap build, I don't see any changes related to the meryl package. Could you please clarify if there should be a separate build script for meryl, or if it's built as part of the winnowmap process?

If a separate build script for meryl is required, could you provide information on where it should be located and what specific changes are needed for aarch64/arm64 support?

recipes/winnowmap/meta.yaml (3)

15-15: LGTM: Build number increment is correct.

The build number has been properly incremented from 2 to 3. This is the correct approach when making changes to the package without changing the upstream version.


16-17: Excellent addition of run_exports section.

The addition of the run_exports section with {{ pin_subpackage("winnowmap", max_pin="x") }} is a great improvement. This ensures that:

  1. Downstream recipes will use compatible versions of winnowmap.
  2. It helps prevent API, ABI, and CLI breakage issues, as mentioned in the PR objectives.
  3. The max_pin="x" setting allows minor version updates while preventing major version changes, striking a good balance between stability and flexibility.

This change aligns well with Bioconda best practices for maintaining package compatibility.


Line range hint 1-17: Verify aarch64/arm64 build support.

The PR objectives mention adding aarch64/arm64 builds for winnowmap and meryl packages. However, there are no explicit changes in the meta.yaml file for aarch64/arm64 support. To ensure the PR meets its objectives:

  1. Please confirm that the existing recipe is compatible with aarch64/arm64 architectures without additional modifications.
  2. If any specific steps or configurations are needed for aarch64/arm64 builds, consider adding them to the recipe.
  3. Verify that the build process and any architecture-specific dependencies are properly handled for aarch64/arm64.

To help verify the aarch64/arm64 support, you can run the following script:

If these tests don't reveal any architecture-specific configurations, it might indicate that the recipe is already compatible with aarch64/arm64. However, please ensure that this is indeed the case and that no additional steps are needed for these architectures.

✅ Verification successful

aarch64/arm64 build support is confirmed.

The review comment did not find any architecture-specific configurations in the meta.yaml or related files. This indicates that the existing recipe is compatible with aarch64/arm64 architectures without requiring additional modifications.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for any architecture-specific configurations or build steps

# Test 1: Check if there are any architecture-specific sections in the meta.yaml
echo "Checking for architecture-specific sections in meta.yaml:"
grep -n -E '# \[(aarch64|arm64)\]' recipes/winnowmap/meta.yaml

# Test 2: Check if there are any architecture-specific build scripts
echo "Checking for architecture-specific build scripts:"
find recipes/winnowmap -type f -name "build*.sh" | xargs grep -n -E '(aarch64|arm64)'

# Test 3: Check if there are any architecture-specific patches
echo "Checking for architecture-specific patches:"
find recipes/winnowmap -type f -name "*.patch" | xargs grep -n -E '(aarch64|arm64)'

Length of output: 569


Script:

#!/bin/bash
# Description: Further check for architecture-specific configurations

# Test 4: Check for architecture specifications in conda_build_config.yaml
echo "Checking for architecture specifications in conda_build_config.yaml:"
grep -n -E '^(archs|host_arch)' conda_build_config.yaml

# Test 5: Check for conditional dependencies or build steps based on architecture
echo "Checking for architecture-specific conditions in meta.yaml:"
grep -n -E '^(  -|  ^)*{{.*(aarch64|arm64).*}}' recipes/winnowmap/meta.yaml

# Test 6: Check for platform-specific classifiers or markers
echo "Checking for platform-specific classifiers in meta.yaml:"
grep -n -E '^(  classifiers:|  markers:)' recipes/winnowmap/meta.yaml | grep -iE 'aarch64|arm64'

Length of output: 690

recipes/meryl/meta.yaml (3)

17-17: LGTM: Build number increment is appropriate.

The build number has been correctly incremented from 0 to 1. This is the right approach when making changes to a package without altering its version, especially when adding support for new platforms.


Line range hint 1-52: Overall changes look good, with one point to address.

The main changes in this PR, including the build number increment and the addition of new platforms (linux-aarch64 and osx-arm64), align well with the PR objectives. These changes will enable the package to be built and distributed for ARM-based Linux and macOS systems, expanding its compatibility.

However, there's an inconsistency between the AI-generated summary and the actual changes regarding indentation corrections. This needs to be clarified and addressed if these changes were intended.

Once this inconsistency is resolved, the PR looks ready for further processing.


45-47: LGTM: New platforms added as intended.

The addition of 'linux-aarch64' and 'osx-arm64' to the 'additional-platforms' list is in line with the PR objective. This change will enable the package to be built and distributed for ARM-based Linux and macOS systems, significantly expanding its compatibility.

To ensure that the build configurations for these new platforms are correctly set up, please run the following script:

✅ Verification successful

To further verify the build configurations for the new platforms, I'd like to examine the 'meryl' recipe file more closely. Let's run another script to inspect its contents.


LGTM: New platforms correctly added without need for architecture-specific modifications.

The addition of 'linux-aarch64' and 'osx-arm64' to the 'additional-platforms' list in the meryl recipe is appropriate. The recipe doesn't contain any architecture-specific build instructions or dependencies for these new platforms, suggesting that the package should build similarly across different architectures.

The existing configuration, including the use of different OpenMP libraries for macOS and Linux, is standard practice and should work for the arm64 architectures as well.

To ensure full compatibility, it would be beneficial to perform test builds on these new platforms:

  1. linux-aarch64
  2. osx-arm64

This will help verify that the package builds and functions correctly on these architectures without any unforeseen issues.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify build configurations for new platforms

# Test: Check if there are any platform-specific build instructions or dependencies
rg --type yaml "(linux-aarch64|osx-arm64)"

# Test: Verify if there are any skip conditions that might affect the new platforms
rg --type yaml "skip:"

# Test: Check for any compiler specifications that might need adjustment for the new platforms
rg --type yaml "compiler\('.*'\)"

Length of output: 349541


Script:

#!/bin/bash
# Description: Inspect the meryl recipe file for architecture-specific configurations

# Display the contents of the meryl recipe file
cat recipes/meryl/meta.yaml

# Check for any conditional statements related to architecture
grep -n "aarch64\|arm64" recipes/meryl/meta.yaml

Length of output: 1442

@martin-g
Copy link
Contributor Author

martin-g commented Oct 4, 2024

The ARM64 builds due to marbl/meryl-utility#3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
aarch64 Related to adding linux-aarch64 support osx-arm64 Related to adding osx-arm64 support
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant