Unify Compilation Process for Native Extension

[marcoroth]

Originally posted by @karreiro in #13

Question

The way we currently build the native extension involves two phases—one with the Makefile in the root and another generated by ext/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:

.
├── Gemfile
├── ext
│   └── erbx
│       ├── extconf.rb
│       ├── extension.c
│       ├── extension.h
│       ├── test
│       │   ├── lexer_test.rb
│       │   └── test_helper.rb
│       └── test.rb
├── src
│   ├── array.c
│   ├── ast.c
│   ├── buffer.c
│   ├── erbx.c
│   ├── include
│   │   ├── array.h
│   │   ├── ...
│   │   └── version.h

To something like this:

.
├── Gemfile
├── ext
│   └── erbx
│       ├── erbx.c
│       ├── erbx.h
│       ├── extconf.rb
│       └── src
│           ├── array.c
│           ├── ast.c
│           ├── ...
│           └── buffer.c
├── lib
│   ├── erbx
│   │   ├── erbx.bundle
│   │   └── version.rb
│   └── erbx.rb

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.rb seems like a more straightforward convention to follow.

[marcoroth]

Cross-posting this from #13 for visibility:

Ideally we could simply the process with these suggestions, 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 it would make sense to keep it the way it is. 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.

[karreiro]

this project is primarily meant to be a C-Project

Good call, I believe it's fair to close this issue for now with that in mind.

When we publish the gem, we can revisit this decision only if users face friction when building the gem from source. For now, I don't see a strong reason to change the directory layout solely to align with conventions of other gems with native extensions.

@marcoroth, I'll defer to you to close this issue (I'm not sure if you'd like to keep this open) -- thank you for keeping this thread available for future reference 🚀

[marcoroth]

I'm quite happy with the setup/structure and compilation process as-is.

So I'm going to close this issue for now, since I don't think that it makes sense to put libherb into the Ruby C-extension. Thanks for the initial idea @karreiro! 🙏🏼