-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Rebuild MaSuRCA recipe #51662
Rebuild MaSuRCA recipe #51662
Conversation
📝 WalkthroughWalkthroughThis pull request introduces several changes across three main files related to the Masurca software installation and build process. In the Possibly related PRs
Suggested labels
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this 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 (1)
recipes/masurca/0001-install.sh.patch (1)
13-14
: Consider simplifying the cp command flagsThe change from
cp -a
tocp -arf
adds redundant flags, as-a
already implies recursive copying (-r
). Additionally, the force flag (-f
) might mask potential issues during installation.Consider keeping just
cp -a
unless there's a specific reason for the force flag:-(cd Flye && make && cp -a ../Flye $DEST); +(cd Flye && make && cp -a ../Flye $DEST);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- recipes/masurca/0001-install.sh.patch (1 hunks)
- recipes/masurca/build.sh (1 hunks)
- recipes/masurca/meta.yaml (2 hunks)
🧰 Additional context used
🪛 Shellcheck
recipes/masurca/build.sh
[warning] 4-4: BOOST_ROOT appears unused. Verify use (or export if used externally).
(SC2034)
🔇 Additional comments (8)
recipes/masurca/build.sh (3)
5-5
: LGTM! Environment variables are properly configured.The changes improve the build configuration by:
- Using consistent quoting for all path variables
- Correctly appending to
LDFLAGS
instead of overwriting- Setting appropriate paths relative to
${PREFIX}
Also applies to: 8-11
7-7
: 🛠️ Refactor suggestionConsider the implications of aggressive optimization.
The change from
-O2
to-O3
enables more aggressive optimization. While this might improve performance, it can potentially:
- Increase build time
- Cause larger binary size
- Lead to unexpected behavior in some cases
The
-I${PREFIX}/include
inCXXFLAGS
is redundant sinceCPATH
is already set.#!/bin/bash # Check if other bioconda recipes use -O3 echo "Checking optimization levels in other bioconda recipes..." rg -l "export CXXFLAGS.*-O3" recipes/Consider these changes:
-export PERL_EXT_LDFLAGS="-shared -O3 -fstack-protector" +export PERL_EXT_LDFLAGS="-shared -O2 -fstack-protector" -export CFLAGS="${CFLAGS} -O3 -std=gnu90 ${LDFLAGS}" +export CFLAGS="${CFLAGS} -O2 -std=gnu90 ${LDFLAGS}" -export CXXFLAGS="${CXXFLAGS} -O3 -std=c++14 -I${PREFIX}/include ${LDFLAGS}" +export CXXFLAGS="${CXXFLAGS} -O2 -std=c++14 ${LDFLAGS}"Also applies to: 12-13
4-4
: Verify BOOST_ROOT usage in the build process.The
BOOST_ROOT
variable is set but appears to be unused. Let's verify if this is required by the MaSuRCA build system.🧰 Tools
🪛 Shellcheck
[warning] 4-4: BOOST_ROOT appears unused. Verify use (or export if used externally).
(SC2034)
recipes/masurca/0001-install.sh.patch (1)
9-10
: LGTM: Good addition ofautoreconf
The addition of
autoreconf -if
is a good practice when rebuilding packages, as it ensures the build system is properly regenerated with current autotools versions.recipes/masurca/meta.yaml (4)
25-28
: LGTM: Build dependencies align with autotools usageThe addition of autotools-related build dependencies (automake, autoconf, libtool, pkg-config) is appropriate given the use of
autoreconf
in the installation process.
47-52
: LGTM: Improved metadata documentationThe changes enhance the recipe metadata by:
- Using consistent quoting for URLs
- Adding development and documentation URLs
- Specifying a more precise license family (GPL3)
15-15
: Consider impact of looser version pinningThe change from
max_pin='x.x'
tomax_pin='x'
makes the version constraint less strict. This means downstream packages will accept any minor version updates, which could potentially lead to compatibility issues if there are breaking changes in minor releases.Also applies to: 18-18
11-12
: Verify patch file existence and contentsThe addition of the patch file aligns with the new build dependencies. However, let's verify its presence in the repository.
✅ Verification successful
Let me generate additional shell scripts to verify the patch file existence and its contents.
Patch file exists and is properly formatted
The patch file exists and contains valid modifications to the installation script:
- Adds
autoreconf -if
step for proper autotools configuration- Changes
cp -a
tocp -arf
for more reliable file copyingThe patch file is present and properly formatted, addressing the concern in the review comment.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if the patch file exists and show its contents if [ -f recipes/masurca/0001-install.sh.patch ]; then echo "Patch file exists. Contents:" cat recipes/masurca/0001-install.sh.patch else echo "ERROR: Patch file not found!" fiLength of output: 322020
Script:
#!/bin/bash # Check if the patch file exists and show its contents ls -l recipes/masurca/0001-install.sh.patch cat recipes/masurca/0001-install.sh.patchLength of output: 924
Describe your pull request here
Please read the guidelines for Bioconda recipes before opening a pull request (PR).
General instructions
@BiocondaBot please add label
command.@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:with
...
being one of:{{ pin_subpackage("myrecipe", max_pin="x") }}
{{ pin_subpackage("myrecipe", max_pin="x.x") }}
{{ pin_subpackage("myrecipe", max_pin="x.x") }}
(in such a case, please add a note that shortly mentions your evidence for that){{ pin_subpackage("myrecipe", max_pin="x.x.x") }}
(in such a case, please add a note that shortly mentions your evidence for that){{ pin_subpackage("myrecipe", max_pin=None) }}
while replacing
"myrecipe"
with eithername
if aname|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
@BiocondaBot please add label
please review & merge
label.@BiocondaBot please fetch artifacts
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>
.