-
Notifications
You must be signed in to change notification settings - Fork 970
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
[feature] I think we need to add a new package type for source code packages #16953
Comments
Thanks for the suggestion. It would be necessary to step back, probably a lot, to understand the use cases, the problems that are being solved, etc. What is the meaning of depending on a source package? How are the consumers using that code inside that package? Also, it is already possible to put code inside Conan packages and use them as regular |
Hi @M0rtalPhe0nix , we also have some cases where we package sources into Conan packages. But we use |
Thanks for the feedback @dkoerner-festo
Indeed, header-library packages are "source" packages in this sense, so this would be better than using packages in the "build" context. If they contain source code |
In our case we provide the package folder as CMake variables to the consumer: In generate():
This works, but it feels more than a workaround, not a final solution. In the consumer CMakeLists.txt we use this variables to access the sources/header. |
Yes, this is what I mean. The way to use something like this is just a convention in the consumer side, there is not a general way to "consume sources" from a dependency in the same way a library can be consumed with |
At least I haven't found a solution. |
Hi @memsharded
because these source code packages has a lot of prebuild configurations that the consumer needs to configure before building it. why not use conan file settings and options for this ? you may ask . it is because the number of options can reach thousands and we have an internal tool dedicated for this configuration.
Because in my current setup I need source code packages not to be propagated upstream if it was consumed previously by a binary package (static/shared) libs
in my case it is a way to allow the first source code package to configure some of the configurations parameters of the second package and allow the consumer of both packages to configure rest of the parameters |
Not sure if I understand. Are they source code packages, or do they contain prebuild binaries? Are they actually building library-like artifacts for the package, but those binaries are not being stored or reused, are they always being built from source? Or they are directly built by the consumers of the package, by adding the list of sources to the build targets of the consumer project?
You can use something like
I am afraid that I might be missing a lot of context and understanding of the setup. From the above, it seems the "configuration parameters" are not Conan settings/options, so not sure how this configuration would work or propagate. |
yes they are . and the prebuild configurations I was talking about is source code configurations are like a group of (#defines) and code behavior configuration .they don't contribute to the build but to the behavior of code itself . and they don't contain any prebuilt binaries .
they are directly built by the consumer of the package .
the scenario described in this picture happens when I make all my source code package To be honest I am on a bit of a predicament where I want to make all the packages that is sources code be visible as long as the consumer is also a source code packages . but if the consumer will build the I don't want to have them propagated upstream . in simpler terms I want the source code packages to be visible upstream until they are built . |
What is your suggestion?
Hello all,
in alot of cases produced packages needs to be a source code package that its build has to be defined from the consumer side . currently we tend to use the package_type
build_scripts
, which for the current time serves the purpose of defining source code packages. but recently we had a bit of a strange scenrio that resulted from our improber use of thebuild_scripts
package type as its default visible trait is false which leads to the unfortunate scenario where we have multipe source code packages with different version in the dependency graph without raising a confilict or resolution of the different requirements of the package to a suitable version . I have attached an illastrative example about this case in the attached image . so according to my current understanding I think an ideal case would be to have native support for source-code packages from conan itself .Have you read the CONTRIBUTING guide?
The text was updated successfully, but these errors were encountered: