-
Notifications
You must be signed in to change notification settings - Fork 8
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
Demonstrate how to configure a cpp-library with multiple source sets #974
Comments
Thanks for this demonstration issue. Its certainly possible, but requires quite a bit of configuration. We will start with samples and see what we can improve to make it simpler for the users. |
@jamie-walker do you have an example handy for what you're trying to do? Why do some of the files need different compiler arguments? |
@big-guy: we target different cpu instruction sets for some of the source files: e.g. SSE or AVX. I could probably make different libraries with the different optimisation levels as a workaround. However, there is quite a bit of shared code so this would involve splitting what is currently quite a tiny library into three: a header only lib for the shared bits, an SSE lib and an AVX lib. I could see this also being useful if we had some code that required e.g. fast-math but other parts of the same library where we didn't want any optimisations that changed the result of the calculations. |
May be it is not related to this issue, but I have a requirment to compile C sources & C++ source located in the same directory as
The output.txt is showing that only *.cc and *.cpp sources are compiled, but no one *.c sources: Thus I am wondering how to configure the source set to include C sources? |
@zosrothko The sample you are providing is only configuring a new |
@lacasseio My comment was just exposing the beginning of the
And please, take a look to the Below the list of the
|
You are right @zosrothko. This seems to be a limitation with how the source view is calculated. We are probably being a bit too restrictive in the sense that the default location should include the pattern filter for the specific source. However, if you specify your own pattern, you should be allowed to specify any files ending/filter pattern. One of the main driving force for the new plugin is the configuration should scale in complexity with how complex it your project. Simple projects have nothing to specify. For example, custom file location will need to specify it's own source extension filtering like you are doing. To move forward with this, I would create a PR for the following:
There is still one open question: Does just changing the only the location should still include only the default source extension? I think that if you are opinionated about where the files are, you should also be opinionated about what source extension you want from that location. @zosrothko Do you want to provide a PR for this? |
@zosrothko The workaround at the moment is shown here: https://github.com/gradle/native-samples/blob/master/c/application/build.gradle#L13-L14. |
Hello Daniel
Le 12/02/2019 à 19:54, Daniel Lacasse a écrit :
You are right @zosrothko <https://github.com/zosrothko>. This seems to
be a limitation with how the source view is calculated
<https://github.com/gradle/gradle/blob/master/subprojects/language-native/src/main/java/org/gradle/language/nativeplatform/internal/DefaultNativeComponent.java#L69-L73>.
We are probably being a bit too restrictive in the sense that the
default location should include the pattern filter for the specific
source. However, if you specify your own pattern, you should be
allowed to specify any files ending/filter pattern. One of the main
driving force for the new plugin is the configuration should scale in
complexity with how complex it your project. Simple projects have
nothing to specify. For example, custom file location will need to
specify it's own source extension filtering like you are doing.
To move forward with this, I would create a PR for the following:
* Add coverage for changing the source location to another location
with the same extension (.cpp or .swift)
* Add coverage for compiling C++ files with another source extension
from the default location
* Add coverage for compiling C++ files with another source extension
from a different location
* Move the matching of the pattern when |getFrom().isEmpty()|
condition only for C++.
* Swift should still behave the same way.
There is still one open question: Does just changing the only the
location should still include only the default source extension? I
think that if you are opinionated about where the files are, you
should also be opinionated about what source extension you want from
that location.
I have a different view on source extension that I will explain later,
but to answer to your question, changing only the source location should
not change the default source extension since one can change also the
source extension at the same time.
@zosrothko <https://github.com/zosrothko> Do you want to provide a PR
for this?
Let's try to build this PR but I think I will need your help for the
coverage...
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#974 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AG7RgTN1gbendv_6tLodPd4KurvSo7PPks5vMw3SgaJpZM4aBwvd>.
|
I agree that we should be able to query the source For example, a user could add one |
I think something is missing in the source block when a directory contains sources from different languages. Here a use case Let say one have a single directory with sources like
Unless misunderstanding from my side, there is currently no way to associate each kind of source with its proper compiler and the proper language options. For example on Windows, it would be usefull to link
|
This is working as expected. Multi-sources components have been ignored at the moment so all source will be compiled as C++ source. To compile C source with a C compiler, see the sample demonstrating this. It will change in the future, but at the moment it's something we haven't looked into. We are unsure if the software model approach was the correct one. |
This issue should only demonstrate how to have same language sources that are compiled differently (or completely excluded from a specific variant of the component). Multiple language source for component should be demonstrated as another sample. |
Hello, I just wanted to ask if the original question from @jamie-walker has been addressed and we have an example? |
See gradle/gradle-native#974 Signed-off-by: Francis ANDRE <francis.andre.kampbell@orange.fr>
The use-case we have for this is a (JNI) shared library where different source files use different compiler options.
This is supported in the old software model by declaring multiple source sets. I'm not sure how to do this using the new cpp-library plugin.
The text was updated successfully, but these errors were encountered: