-
Notifications
You must be signed in to change notification settings - Fork 960
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
[question] Handling package that is platform and variant agnostic but not the tests in the package #16330
Comments
Hi! Thanks a lot for your question. Depending on your current workflow, the easiest way might be to decouple the package creation from the package tests. (A question remains to wether having such complex tests is in the spirit of the Conan's test_packages) When you run Let me know if that helps :) |
Some extra info after re-reading your question (Thanks @memsharded for the headsup!) Note that you can also call |
We use conan build + conan export-pkg. I do not see -tf option for conan build. |
The It is not the |
Not sure if I was clear and we understand each other. https://docs.conan.io/2/tutorial/creating_packages/test_conan_packages.html |
I think the problem is that we might be talking about different things:
What is exactly your case? testing functional/e2e that doesn't require internal private headers? Then, the second important thing to understand is if you want to actually package your tests and test results. In most cases it is not necessary to package the tests and the test results are just output in CI for red/green, but not really packaged. If you don't need to package the tests and test results, the
|
It is functional or e2e tests for the tools package. And the tools package generates a binary that shall be available to the functional /e2e tests. The functional tests depend on the platform and variant as they generate code using the binary from tools package and compile and run the tests. My intension is not to package the tests but to be able to execute the tests. My dilemma is should i move the functional/e2e tests to another package or live in the same package? As the tools binary is using default Windows configuration while generated code in the tests folder need platform and variant configuration in order to compile, run static code analysis on the generated code. |
If you are not packaging the tests or tests results, then you don't need another package, you just need a simpler The In both cases, both with the The only thing is that you might want to do a
In general it would be less work and less maintenance if the tests are in the same package repo in I am not sure if I am fully understanding the question, please let me know if the above makes sense to you. |
I will try based on your suggestions and get back to you, The thing is the functional tests are not very straight forward(due to legacy reasons, nothing to do with conan offcourse )in our use-case. |
Sounds good, keep me posted, thanks for the feedback.
The thing is that such complexity will still be there, no matter if you use the |
We have a cross compilation use-case. If I provide --build-missing argument, then it tries to build the missing binaries(inspite of providing build and host profiles) with default configuration instead of picking pre-built binaries from the conan remote. The structure of my folders are:
|
This shouldn't be the case. The If you want to know why some binary is missing, you can try with the The setup should be pretty straightforward:
|
Ctest_package.zip |
This is not fully clear. If the package is configuration agnostic, it doesn't depend on a specific profile, it can be built with any profle. If that is not the case, then it is not configuration agnostic. The typical use case is a header-only library, it is configuration agnostic, it doesn't matter in which platform or with which profile you build the package, the package will always end with the exact same headers packaged (and the same exact In the recipe that you provided, you still have
|
The package itself does not need any configurations but the tests that use the binary of the package do need the configuration(build profile and host profile). Yes the tests will get different package_id for different configurations. In that case, will the above method work meaning using conan create . --build=missing and having a conanfile.py at the top level and another one in test folder? Or the only way is to seperate the package and the tests itself. In my case, the package itself is not dependning on a specifi cprofile but the tests are. |
Yes, I think this works, and in general will be more integrated and automatic than having a different separate package. |
Sorry but how do the tests get the profile information if I trigger with conan create . --build=missing? I changed the package but I still miss the information regarding how shall the test_package know against which configurations shall it test. |
See the code attached:
|
Yes I understood the attachment . Thanks very much for it. If I use conan build then, conan export-pkg would trigger the tests with the command:
|
Is it not allowed to use the build() method in the top level conanfile.py? In the package () method is it not allowed to use self.run(cmd) for compiling the binary for the package before running the tests with export-pkg? |
But if you build something, then the binary will not be really platform independent? Or you are only building and running tests.
|
Thanks for your reply. I have the build method to build a matlab toolbox package which is a binary , this is a matlab command, it is not depending on any settings. All your provided inputs and suggestions work. However I would have one last question:
And in the test/conanfile.py , the test method contains:
|
Sorry I figured out with : ctests = self.conf.get("user.build:ctests", default="") |
Yes, that looks good, the way to get conf values in your code. |
It works but if I would like to use layout method with cmake_layout(self), Do I need to additionally handle anything?
|
Sorry I am not sure if I understand the issue or the layout. If you want to update the project we used above, and clarify instructions to reproduce the issue, that would help. |
Sorry It was a corrupted cache issue, fixed now. Is it possible to have the path from self.tested_reference_str ? I need to copy the binaries to a special location to suit some legacy scripts. |
Yes, something like |
I used it like this: self.dependencies.build.get(self.tested_reference_str) , Also works. |
Happy to know that it worked. Thanks for the feedback! |
What is your question?
Hi! I have a question regarding a tools package that needs to be tested. This tool is generating a matlab package but should be tested against simulink models. Simulink models generate code and shall be tested for static code analysis. While the tools package is packaged with no platform and varaint configuration the static code analysis and the compilation of generator code needs the compiler flags and linker flags. In that case, I have thought to make the tests a different package and the tool itself a seperate package. Is this the right way to proceed or is it possible to build the tools package (variant and platform agnostic) and the tests itself(platform and variant specific)?
Thanks!
Have you read the CONTRIBUTING guide?
The text was updated successfully, but these errors were encountered: