search

conda-forge / autotools_clang_conda-feedstock

A conda-smithy repository for autotools_clang_conda.
BSD 3-Clause "New" or "Revised" License
5 stars 6 forks source link

add tests #16

Closed h-vetinari closed 2 years ago

h-vetinari commented 2 years ago

Wanted to fix #15, found I had some uncommitted tests lying around. Let's try these first.

conda-forge-linter commented 2 years ago

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) and found it was in an excellent condition.

h-vetinari commented 2 years ago

@isuruf I managed to reproduce #15 with the tests here (c.f. https://github.com/conda-forge/autotools_clang_conda-feedstock/pull/16/commits/4d6ac64bd5c5ee299b206d94ac3e1842b701b335), but my first guess (making the paths explicit) didn't work out.

There's however some confusion (at least to me) with the various environments here - this feedstock is really only designed to be pulled in at build: time, but now I'm trying to shoehorn it into running at test: time. Perhaps you'd prefer a downstream: test-feedstock like for libcxx (sounds a bit overkill though for an internal tool)...?

h-vetinari commented 2 years ago

@isuruf Would you be able to have a look here? Would be good if we could unbreak this piece of pretty important infrastructure.

isuruf commented 2 years ago

As the package name says, this is for building an autotools package and the test you are adding is not for an autotools package.

h-vetinari commented 2 years ago

As the package name says, this is for building an autotools package and the test you are adding is not for an autotools package.

It's intended to be a minimal reproducer of #15, using the documented calls from the documentation in meta.yaml.

I don't really understand your point - I'm happy to adapt the tests however necessary (or indeed remove them) - but currently patch_libtool is not working

isuruf commented 2 years ago

I don't think you understand what a autotools project is. See https://www.gnu.org/software/automake/manual/html_node/Autotools-Introduction.html

h-vetinari commented 2 years ago

I do get the configure + make workflow, though - admittedly - not how it interacts with patch_libtool here. Are you saying that it's not an autotools projects without a call to configure before (note: the failure is the same regardless)?

The point is that the documentation of how to use this feedstock does not work even with the full monty of an autotools build, c.f.

# Not sure why this isn't working.
# [[ "$target_platform" == "win-64" ]] && patch_libtool

in https://github.com/conda-forge/ffmpeg-feedstock/pull/126 (https://github.com/hmaarrfk/ffmpeg-feedstock/commit/73461b1ec9bae4c7aeac28e0dae30a09fb22689b).

I don't know how important patch_libtool is in the grand scheme of things, but even though I don't understand all the intricacies, I'm trying to fix it.

h-vetinari commented 2 years ago

but even though I don't understand all the intricacies, I'm trying to fix it.

It could be that the fix is documentation-only, but since it worked before, it seemed like there's more to it.

isuruf commented 2 years ago

Are you saying that it's not an autotools projects without a call to configure before

Yes

The point is that the documentation of how to use this feedstock does not work even with the full monty of an autotools build, c.f.

No, ffmpeg is not an autotools project.

Please try a project using this package like mpfr and play around with it to get a feel of how it works.

h-vetinari commented 2 years ago

OK, closing this. I'm thinking the log message for calling patch_libtool only after configure could be made an error in the function itself, but otherwise things should be fine.