-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a proper build system #22
Comments
Autotools would be great! |
Yes, I fully support that! Let me know if I can help (although I don't know much about Autotools) |
Thanks @RubenVerborgh and @mielvds for weighing in, sounds like we have a go-ahead for this. I'll be looking to begin work on it in the next week or so and will report back on progress. I suspect the difficult bit will be handling the bundled libcds library; otherwise this is fairly straightforward to do. |
Great stuff! Indeed, I think this would also greatly help distros! :-) And adds another reason to fix #19. |
Yeah... One month before Ubuntu closes. But I've also seen stuff getting stuck in the approval queue for a long time, so it may not work out anyway. Sorry I don't have any time to help out, but I think distros are important for adoption. |
@kjetilk Right, and 16.04 will be the LTS release, which does mean it is a once-in-two-years window. I agree that it would be valuable to get the library included and distributed. |
@bendiken, yes, that is correct, it is a once-in-two-years window. I'm using Debian on my systems myself, which has a projected freeze date late 2016, but arguably, Ubuntu is an important deployment platform. |
@wouterbeek Thanks for the reminder re: #34. I've been tied up on other fronts, but am catching up and will get back to this soon. |
This is also seems like a good candidate for the debian-package label. |
|
@bendiken Any status update on this? |
Hi. Last year I set an independent repo with libhdt using Autotools. Basically, I created a python wrapper that call libhdt in the backend. Since the current building system produces only static libraries, I decided to create a completely new building system with Autotools. Once it was done, I produce .so/.dylib libraries and I could link python with hdt. I copy part of that code in this PR and adapted a bit. Now, one can produce libraries using any desirable property using configure. I had to do some changes in the code:
There are some issues that had to be addressed/considered:
|
Thanks @ptorrestr, this is great! Why was the rename to |
@RubenVerborgh Just for convention. It makes more sense in my head call the folder "libhdt" than "hdt-lib". It can be changed course. |
Assuming this issue is resolved (feel free to correct me though), as the autotools PR is merged to develop |
Right now, the hdt-lib build process is pretty brittle with regards to platform quirks, and produces only tool binaries and static libraries, not any shared library. Further, building with custom paths or with a selection of features to be enabled/disabled (e.g., Serd, Raptor, zlib, KCB) requires manually editing Makefiles--not at all a welcome practice from a downstream user's point of view.
On POSIX systems, the currently produced static libraries aren't portably linkable with shared libraries that would like to make use of
libhdt
; moreover, on e.g. x86-64 the individual object files that constitute the static libraries would generally need to be compiled with-fPIC
for the libraries to be usable from modern projects. All this requires manually fiddling with flags in bothlibcds-v1.0.12/src/Makefile
andhdt-lib/Makefile
.Additionally, no actual installation facility is currently provided, meaning that users have to manually hunt down built artifacts--which are currently placed in different output directories--and copy them one by one to some installation destination.
All this argues for converting the project to use a proper configuration and build system. The two obvious and realistic choices are Autotools and CMake. Doing this would also greatly facilitate packaging the project for downstream distribution (#19).
I would myself volunteer to convert the project to using standard Autotools, which would give users the familiar
./configure && make && sudo make install
workflow that works reliably on all platforms and resolves all aforementioned problems.The text was updated successfully, but these errors were encountered: