KhronosGroup
It would be nice if the zip file actually included what is needed, Git isn't always an option
Some of us have security to deal with. Using git apps and so on isn't an option. So actually including the required files in the zip should be a basic common sense thing here.
Hello, thank you for the report and for trying out the SDK.
I tried this out myself and the problem is that all the sub-folders of 'external' are empty in the zip file, because they're submodules. You can't run the git submodule commands because the folder is not a git repository.
A workaround could be manually dropping in the source from the zip files of the synchronized release of the three respective repositories, but that is pretty tedious when we want the SDK to "Just Work". It is also not documented. I did test this and it does work.
A quick search suggests that GitHub can't include submodules in releases directly, but perhaps it is possible via a CI action.
So the only way someone can get and make use of this is if they install gitdesktop or manually go through and download everything off each of the separate repositories.
There is no good excuse for this.
We have subfolders for a reason. Stop using symbolic links external repositories. It doesn't make this any cleaner.
Hell the code is a mess from hell because they are using code space for documentation. Simply, remove the old code let people who used to use older functions read the documentation. Do like everyone else create a wiki and explain that XYZ are deprecated rather than clogging up code space with trash. That's what it is when it is deprecated trash! It should just be removed. It's the developers job that uses the library to read documentation. If you do that you can get rid of all the stupid pragmas and garbage telling people that stuff is deprecated. At the rate you are going in this repository eventually there will be more code dealing with what is deprecated than the actual usable code.
You want your repository to be usable. That's not searching or downloading more than one thing. It isn't having a code base that looks like this. You want people to be able to open your header file and look at the stuff they want to use if they have a question. That's the classes, the function declarations and so on. They shouldn't have to wade through a swamp of code telling them what isn't usable. What isn't usable doesn't help me or most of us. Only knowing what is usable does.
@alycm I'm certain this can be done using GA. We'll need to make an action that creates a binary releases when a tag is pushed.
@hayesgr Apart from agreeing with you on simplicity first, please be a little more careful with wording.
As for your feedback, the OpenCL ecosystem has had the OpenCL-Headers, OpenCL-ICD-Loader and OpenCL-CLHPP repos for ages, and while you may think that everything should just be part of this SDK repository, doing so we would likely draw the anger of many Linux distro maitainer's anger, whom have specific packages targeting these repos. If we shuffle existing things around, we will break many automation scripts in the wild or duplicate a lot of code. (I personally would love your monorepo approach, rest assured it crossed our minds too.) Git submodules is the way in Git-land to deal with projects that are scattered throughout multiple repos but really are one thing. Welcome to OpenCL-SDK.
Having source tarballs and binary releases is something we can definitely do, but it does take some effort (something which is always in short supply). Should you be up for the task, do not hesitate to open a PR with such a solution. To reduce friction, I would advise basing your work on top of #37 which has a fair amount of CI rework which will be needed when taking care of Windows/Linux/MacOS binaries. It does depend on a few other PRs in flight (all linked in the PR description) but all should make its way upstream soon enough.
That's what we call the python approach to stuff. Because we poorly planned out something to start with and people got used to it and it would break their code we aren't going to fix it. Can you imagine if all of us used that lame excuse were programming would still be. Imagine were C++, C, Java, .net all would be if they held on to an excuse like that as a reason not to do something.
@hayesgr Are the new manually packaged source archives in the releases solve this issue for you?