Skip to content
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

Rid use of non-portable gnat specific code. #2

Open
charlie5 opened this issue Dec 14, 2016 · 6 comments
Open

Rid use of non-portable gnat specific code. #2

charlie5 opened this issue Dec 14, 2016 · 6 comments
Assignees

Comments

@charlie5
Copy link
Owner

Mostly to do with process & command argument handling.

@charlie5 charlie5 self-assigned this Dec 14, 2016
@mgrojo
Copy link
Contributor

mgrojo commented Sep 16, 2023

Is this the reason why the crate specifically depends on gcc 11.2.4? I'm thinking in using your crate, but I'm afraid of limiting the availability of my crate by this requirement. Could it at least the requirement be reduced, like depending on any GCC 11 version?

@charlie5
Copy link
Owner Author

hi @mgrojo

Ashell should be buildable with any GCC version >= 11.2.4 and with 'florist_blady' crate version >= 6.0.0.

I'm currently in the process of updating the ashell alire.toml file to reflect this.

Thanks for your interest.

@mgrojo
Copy link
Contributor

mgrojo commented Sep 17, 2023

Thanks for the quick response.

By the way, maybe you can shed some light to why a simple crate using withing your crate fails due to warnings being treated as errors. You can see the simple test reproducer in alire-project/alire#1386 (comment)

I searched for some switch in your repository that activates the -gnatwe switch and found nothing. So the question is where that behaviour is coming from.

In my case, I suppose the GCC version was coming from Ubuntu's gnat-10. After updating to gnat-11, I cannot longer reproduce the issue. Is then GCC 10 the one to blame for warnings being treated as errors without asking for it?

Edited: sorry, it is still failing, I forgot to do alr build after alr with ashell.

@charlie5
Copy link
Owner Author

@mgrojo

Yes, I've seen this before in florist_blady project, which treats warnings as errors. The warnings are due to newer GCC versions checking for more unnecessary 'with's. I submitted a pull-request to fix these to blady's florist github repo, which was accepted. I am guessing he has not as yet made a new alire release with these changes.

It's quite late here and I'm a bit tired. I'll investigate properly tomorrow and let you know the result.

@mgrojo
Copy link
Contributor

mgrojo commented Sep 17, 2023

It's a strange problem, because only withing florist_blady, the problem is not reproduced, so I cannot understand where is -gnatwe added (or equivalent, maybe gprbuild -we). In any case, I'd expected one of those switches to appear in the crate directory, doing a recursive grep, but it doesn't find anything.

@mgrojo
Copy link
Contributor

mgrojo commented Sep 17, 2023

I know now where is the problem in the grep searching, those warning switches can be joined together, and looking for -gnatw.*e it finds the problem:

alire/cache/dependencies/florist_blady_6.0.0_3bc476cc/florist.gpr:            for Default_Switches ("Ada") use ("-g", "-gnatw.eH.YD", "-gnatyg", "-Wall",
alire/cache/dependencies/florist_blady_6.0.0_3bc476cc/gnatsocks/gnatsocks.gpr:            for Default_Switches ("Ada") use ("-g", "-gnatwae", "-gnatyg");

So I will open an issue in florist_blady suggesting removing that switch for the general profile used by the crate, otherwise any future warning raised by a compiler will make the crate to fail. This is good for the library developer, but not for the mere user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants