What should the folder layout of our binary distributions be

[abadams]

The options are:

Option A:

./Halide-12.0.0-x86-64-linux
./Halide-12.0.0-x86-64-linux/share
./Halide-12.0.0-x86-64-linux/share/doc
./Halide-12.0.0-x86-64-linux/share/doc/Halide
./Halide-12.0.0-x86-64-linux/share/doc/Halide/search
./Halide-12.0.0-x86-64-linux/share/Halide/tutorial
./Halide-12.0.0-x86-64-linux/share/Halide/tutorial/figures
./Halide-12.0.0-x86-64-linux/share/Halide/tutorial/images
./Halide-12.0.0-x86-64-linux/share/Halide/tools
./Halide-12.0.0-x86-64-linux/include
./Halide-12.0.0-x86-64-linux/lib
./Halide-12.0.0-x86-64-linux/lib/cmake
./Halide-12.0.0-x86-64-linux/lib/cmake/Halide

Pros: can mostly be directly unpacked into /usr/local (minus top-level directory). Aims to be identical to an eventual .deb file (though lib might need an x86_64-linux-gnu subdirectory).

Minor con: requires different relative paths from tutorials to the includes compared to a source checkout so we'd have to rework the top comment in each tutorial

Option B is a flatter version of the above, more similar to our current releases:

./Halide-12.0.0-x86-64-linux
./Halide-12.0.0-x86-64-linux/doc
./Halide-12.0.0-x86-64-linux/doc/search
./Halide-12.0.0-x86-64-linux/tutorial
./Halide-12.0.0-x86-64-linux/tutorial/figures
./Halide-12.0.0-x86-64-linux/tutorial/images
./Halide-12.0.0-x86-64-linux/tools
./Halide-12.0.0-x86-64-linux/include
./Halide-12.0.0-x86-64-linux/lib
./Halide-12.0.0-x86-64-linux/lib/cmake
./Halide-12.0.0-x86-64-linux/lib/cmake/Halide

Pros: Makes docs and tutorials very visible. Less of a change from our existing releases. Flatter.
Cons: While it can also be untarred into /usr/local in a manner similar to cuda or other SDKs (with top-level Halide directory preserved), the cuda approach is non-standard and will require explicit linker and include paths.

[abadams]

Alex and I can't agree and Steven does not feel informed enough on packaging to make the call, so opinions from @zvookin @jrk @shoaibkamil and anyone else who wants to weigh in would be very helpful.

[steven-johnson]

While I am not very informed on packaging, based on the pros and cons you list, Option A seems preferable to me; it has an apparently-clear pro, and the minor con seems easily fixable by updating comments.

[shoaibkamil]

I don't have a strong opinion about this, but I slightly favor option 1. I don't think the con there is such a big deal, and the non-standard-but-slightly-flatter approach doesn't seem to have a lot of advantages. Option 1 can still be used in the same way as option 2, which is similar to what homebrew does (just preserve the top-level Halide-12.0-x86-64-linux dir and you can have multiple versions installed, but need explicit compiler/linker flags).

[jrk]

Indeed, my take is the same as @steven-johnson. The pros seem clear (and it’s always bugged me how nonstandard our layout has been in the past.) The con seems easy to work around quickly to start, and in the long run seems more like a statement that how we build and use tutorials in-tree in a git checkout should be rethought a bit more coherently.

[zvookin]

I think the first option is probably the way to go. I feel like it is definitely where the docs belong. For the includes issue, it seems like the include path is the solution. There are a few ways to go there. Adding both -I../../include and -I../../../include would work nicely, but is a bit capricious. We could also just change the repository to move the tutorials.

[abadams]

Thanks all, resolved in favor of option A.