This repository was archived by the owner on Mar 11, 2026. It is now read-only.
Build System Refactor#15
Open
jflopezfernandez wants to merge 3 commits into
Open
Conversation
I thought that the project structure was a little weird, and using bash scripts and a build-and-configuration system seemed like the worst of both worlds, so I refactored both the project and the build system. As it currently stands, to build the project, you simply run ./configure && make, and the project is good to go. The gengetopt files still get generated, but they are explicit dependencies now, which the makefile generated by autoconf handles. It also still generates the config.in.h header, but now it puts it in the dedicated include folder, where all of the headers live. I also removed the multi-levelled header and source file structure, as I'm not sure it really served a purpose, since all of it was a single project, rather than a group of projects that built separate libraries and then linked together. To modify the header and source file include directives, I just used a sed script to delete the ../(impl|io|index)/ part of the include statement. I also updated the README file, and it now clearly indicates that the project requires gengetopt. It successfully built with multiple version of GCC, Clang, and ICC, all of which are listed on the readme (the version that were tested, that is). It also explains how to build the project, as well as some of the lmitations of the refactored version, as it currently stands. For example, while you can configure the CFLAGS, CPPFLAGS, LDFLAGS, and CC variables as normal, the compiler indicated by CC is currently used as the linker driver. This implicit dependency is on the chopping block as this refactor continues. While the project does build and is configurable, this is still very much a work-in-progress, as the full flexibility of the autotools toolset isn't being used to its full potential. I will be referencing this issue in the commit, I just had to actually create it, per the contributing guide. Issue NationalSecurityAgency#14
The configuration script was also further refactored, and now libraries are explicitly looked for, rather than the previous method of searching for a header they included. The entire build process is now a functional three step canonical build consisting of 'configure', 'make', and 'make install'.
Author
|
The most recent commit now implements installation and uninstallation functionality. In addition, the configuration process specifically searches for the libraries themselves, rather than searching for headers they include. The application can now be installed using the usual: ./configure
make
make installThe README was updated accordingly, as well, and the application version, which was set incorrectly on the original commit, is now correct once again, by using the version directly from |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I thought that the project structure was a little weird, and using bash scripts and a build-and-configuration system seemed like the worst of both worlds, so I refactored both the project and the build system.
As it currently stands, to build the project, you simply run ./configure && make, and the project is good to go. The gengetopt files still get generated, but they are explicit dependencies now, which the makefile generated by autoconf handles. It also still generates the config.in.h header, but now it puts it in the dedicated include folder, where all of the headers live.
I also removed the multi-levelled header and source file structure, as I'm not sure it really served a purpose, since all of it was a single project, rather than a group of projects that built separate libraries and then linked together. To modify the header and source file include directives, I just used a sed script to delete the ../(impl|io|index)/ part of the include statement.
I also updated the README file, and it now clearly indicates that the project requires gengetopt. It successfully built with multiple version of GCC, Clang, and ICC, all of which are listed on the readme (the version that were tested, that is). It also explains how to build the project, as well as some of the lmitations of the refactored version, as it currently stands. For example, while you can configure the CFLAGS, CPPFLAGS, LDFLAGS, and CC variables as normal, the compiler indicated by CC is currently used as the linker driver. This implicit dependency is on the chopping block as this refactor continues.
While the project does build and is configurable, this is still very much a work-in-progress, as the full flexibility of the autotools toolset isn't being used to its full potential. I will be referencing this issue in the commit, I just had to actually create it, per the contributing guide.
Issue #14