Skip to content
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

Open
jflopezfernandez opened this issue Jun 5, 2019 · 1 comment
Open

The project and buildsystem could use a good refactor #14

jflopezfernandez opened this issue Jun 5, 2019 · 1 comment

Comments

@jflopezfernandez
Copy link

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.

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
This was referenced Jun 5, 2019
@Montana
Copy link

Montana commented Aug 20, 2021

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants