-
Notifications
You must be signed in to change notification settings - Fork 107
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
The project and buildsystem could use a good refactor #14
Comments
jflopezfernandez
added a commit
to jflopezfernandez/DCP
that referenced
this issue
Jun 5, 2019
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
Was the reason for the removal of the multi-levelled header and source file structure because of the likelihood of a transposition error? Like the number of files in a program? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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. Thegengetopt
files still get generated, but they are explicit dependencies now, which the makefile generated byautoconf
handles. It also still generates theconfig.in.h
header, but now it puts it in the dedicatedinclude
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 requiresgengetopt
. 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 theCFLAGS
,CPPFLAGS
,LDFLAGS
, andCC
variables as normal, the compiler indicated byCC
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.The text was updated successfully, but these errors were encountered: