Hi everyone,
Swift is applying to participate in Google Summer of Code this year again.
We had some great projects last year (4 out of 4 completed successfully), and this year we wanted to give the community a little bit of a heads up, so you can also come up with your own ideas in case you have some you would like to propose and find a mentor for early.
We are currently collecting ideas, matching them with mentors and slowly putting them up on the (work in progress) Swift.org - Project Ideas for GSoC 2021 site.
If you have other project ideas please feel free to post them here or message me directly and we'll work on polishing them up and try to find a suitable mentor for them.
A project idea should follow a similar structure as the ones on the linked site (i.e. include title, description, expected outcomes, etc).
If and when Swift is accepted as a project for GSoC 2021 we will post another update announcing this here.
March 10 - Organizations Announced (hopefully, including Swift )
March 30 - April 13 - Student Application Period
May 18 - Student Projects Announced
May 18 - June 8 - Community Bonding
June 8 - August 17 - Coding (note the shorter than usual coding period (around 21 days)
Keep in mind that currently we are pretty early in the process, and accepted organizations have not been announced yet. We wanted to give the community a heads up though in case you have some project ideas what might need some longer time to prepare and flesh out before the official Student Application Period begins.
Hello everyone,
I am Abhik, currently in my final year pursuing a BTech in the field of Computer Science at IIT Roorkee, and want to apply for GSoC this time under Swift. I had accomplished past projects involving C, C++, and Java. I have some knowledge of Swift programming language (worked upon an iOS app). It will be great if someone can guide me through the next steps.
Applying to specific topics will begin March 30th. Until then you can make yourself familiar with the proposed topics or think of something on your own and attempt to find a mentor for it. Generally speaking sticking to the existing proposals is better if you don't already have a strong project idea and mentor in mind though.
Hmm... thanks for the writeup, @wtedst. I don’t mean to let you down, but have to be honest that I (personally) don’t think that this is a good summer of code project.
Documenting such internals requires a lot of knowledge about them and it does not really feel like a right kind of task for someone to “learn and document as they go”, i.e. a student during the summer of code. It would have to very heavily rely on the mentor providing much of the information I feel, making the project somewhat less of an independent project of the student which they are intended to be.
The outcome of a project also should be pretty tangible and well defined. With such documentation tasks it is hard to do so because “they never end” quite often. And making a complete in depth and future proof swift compiler hacker guide seems to me like it would take much more time than available in the GSoC period (it's almost like a book project in some way).
To give it a chance though, I will ask around if someone would be interested in mentoring such idea. Thanks for the writeup again, and perhaps if this idea does not make it you could pick up and focus on one of the proposed ones?
A rough idea: Is setting up Windows CI and building a functional build-script for Windows suitable for GSoC? It’s a very specific area, and we need it to make Windows really first-class supported.
Thanks for the idea, I have a feeling that work on CI infrastructure may be hard because it involves access to servers/credentials and in the case of Windows I suppose also includes licensing etc.
@mishal_shah can comment more though if there is any help that would be welcome and enough for a summer of code project to help with windows CI.
@compnerd would be the right person to provide more information about the Windows build system.
If I understand it correctly, the focus for the GSoC project would be to migrate build-windows.bat over to build-script, which can be done without access to the CI servers. Once the build-script is updated to support Windows build, I can update the CI job to use the new build-script preset.
It’s certainly better to use the same build-script across all the platforms if possible. What I originally intend is that the participant may write a more powerful build script for Windows which can support features like cache, test and smoke tests. We can then:
Make toolchain development on Windows far more efficient;
Require tests and smoke tests on Windows for future patches, making sure that a change won’t break Windows build;
Get the Windows toolchain as an artifact of CI, which doesn’t rely on @compnerd ‘s Azure CI any more.
If we can finally use build-script on Windows, another benefit we’ll get is that toolchains on all platforms would share the same layout, though the current layout may be significantly changed on Windows.
This is already effectively done. The build-windows.bat already does the pre-commit CI testing. The commands are also documented.
Could you elaborate on this? I believe that the windows toolchain development is already quite efficient.
This is already done. There is pre-commit CI for the toolchain.
There are additional pieces which are needed for packaging - an unpackaged toolchain is ~10x larger (~4GiB vs 400 MiB) but possible already with the pre-commit CI.
I’ll check it out. It doesn’t quite make sense to me because I’m focusing on Core Libraries and Developer Tools, which build-windows.bat currently lacks support of.
I suppose there isn’t check for Windows for corelibs and other related projects, due to the same reason addressed above?
The reason for the related projects not being tested is capacity. If you can provide hosts for CI, I think that resolving that it would be quite possible.
I think that what would be more useful than build-script would be reworking the tree layout to not have deep paths. There are a few cases where we have >256 characters in paths which is a bigger problem and crops up more commonly with the CI infrastructure.
Just to post an idea if anyone wants to take it on; SPM dependency pre-built caches.
We have a number of dependencies which take a significant time to build so we pre-build them to a cache for our CI. Each CI job then pulls in the cache and saves a significant time on each CI run.
Currently we do this though a combination of Carthage and our own tooling but really want to use SPM. This is one of the last major stumbling blocks for us to adopt it.
)