zhztheplayer commented on PR #5743: URL: https://github.com/apache/incubator-gluten/pull/5743#issuecomment-2111505746
> And there is no reason to separate native configs into different place, since all configs has already been unified in java side. If some design is not solid now, why it can not be changed? This is why I mentioned that we haven't yet do well on module separation. Before we have a clearer design or do a refactor against the base arch of Gluten, I'd suggest keeping Velox backend's code inside its own module, including those in `GlutenConfig.scala`. I had a rough thinking on an ideal shape of code architecture of Gluten, e.g., ``` gluten |- core | |- java | | |- main | | \- shim | |- scala | | |- main | | \- shim | \- cpp |- velox-backend | |- java | | |- main | | \- shim | |- scala | | |- main | | \- shim | \- cpp | ... ``` Which intentionally requires for code separation between kernel and backends. Whether or not we go like this, it's very possible that Gluten keeps attempting to be extensible for different backends. So I see keeping the code separated in their own modules better than union them into core module anyway. > another way is put common configs into GlutenConfig.h and velox configs into velox/VeloxConfig.h, but I dont find the real difference between these. I would second this. Would you like to use that approach, temporarily? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
