Replies: 4 comments 8 replies
-
|
I have long been in favor of this. I think it would be useful to enforce some degree of isolation between components and public/private parts of our API. I am in the process of moving the autoschedulers to For instance, we have this ASLog thing that duplicates our other Error handling for the autoschedulers. If that were factored out as an internal logging library, we wouldn't have to duplicate it or work around exposing parts of the interface to our end users. Everything could just link to it. Another benefit would be to isolate LLVM to only those parts that require it. That will make it easier to produce builds of Halide that do not use LLVM, which is something that has come up in discussions, and will also make it easier to maintain the file lists for Halide.h (right now there's a comment saying, essentially, "please don't put anything here that includes LLVM") |
Beta Was this translation helpful? Give feedback.
-
|
I have also long been in favor of this. To quickly surface past points of discussion:
|
Beta Was this translation helpful? Give feedback.
-
|
In general I support this effort. As a practical matter, let me suggest that we wait until we (finally) do another binary release and start proper semver usage; this sort of rearrangement makes a lot more sense to do once a version-barrier is enacted, IMHO. |
Beta Was this translation helpful? Give feedback.
-
|
What's the status of this? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The number of files in
srcis growing steadily -- I wonder if it is a good idea to group the files in directories. The easiest grouping is to put the simplifying rules into one folder, and to put the codegen files into another folder. Maybe the lowering passes should be in one folder as well.Beta Was this translation helpful? Give feedback.
All reactions