Conversation
d4ef574 to
0c3d54b
Compare
There was a problem hiding this comment.
Hey @karreiro, thanks so much for this improvement!
After cherry-picking some of your commits from here into #3 I merged that PR. Now I rebased this PR off of main which is why there are only 3 commits left now.
But either way, I think they improve the way the project gets compiled!
As per your question, I opened #14 to keep that valid question around.
Ideally we could simply the process with the suggestions you made, but the reason why I personally wanted to keep it separate was because this projects is primarily meant to be a C-Project.
For now, the Ruby gem is just a convenience for testing and ease-of-use. Which is why I feel like it doesn't make sense to let the Ruby extension itself dictate the folder structure of the whole project at this point.
That said, I'm new to writing C, and Ruby C-extensions for that matter. So maybe there is a reason why we'd want to do that.
I think for now in this PR it makes sense to keep it that way. But please let me know if you have any concerns with this approach. I'm more than happy to adapt it at a later point.
What does this PR do?
This PR focuses on getting the project build passing and on incorporating the
compile/cleantasks into the Rakefile. This should help us integrate everything a bit more smoothly into the publishing workflow.Question
The way we currently build the native extension involves two phases—one with the
Makefilein the root and another generated byext/erbx/extconf.rb. While this setup works, it adds an extra point of failure for users compiling the gem from source.What do you think about adjusting the directory structure to have a single compilation process based on
ext/erbx/extconf.rb? We could move from this:To something like this:
I think this change could simplify things and make the build process a bit safer. I do like the current style of the repository, but having just one Makefile, based on
ext/erbx/extconf.rbseems like a more straightforward convention to follow.