Addition of a build system generator

[elfring]

I suggest to reuse a higher level build system so that powerful checks for software features will become easier.

• CMake
• Autotools

[hnes]

Thanks Markus for your nice proposal :D

The reason why I choosed to write a simple bash script make.sh is because:

• The libaco is very simple to build and also has very minimal dependencies on the POSIX.

gcc -g -O2 acosw.S aco.c app_of_libaco.c -o app_of_libaco

• Using bash scripts could make the C flags matrix build process easier and clearer.

But still, adding the higher level build system support could even better.

I would like to add it to the ToDo list and it would be released in the future v1.3.0 since it is not so urgent.

---

Edit:

The reason why there is no such static or shared library makefile for libaco is because:

• There are several C macro config choices in libaco's build;
• The binary of libaco self is so tiny (15k~).

So, I think the best option for the developer is to configure the C macros and compile libaco himself. It would be clearer and is more impossible to make a mistake.

[elfring]

• Does a tool like “autoscan” show any software dependencies that you find worth for further considerations?
• How do you think about to support more development environments by the reuse of build system generators?

[hnes]

Maybe I'll choose to use CMake, but the priority of this issue is not so high.

[hnes]

I have just committed a simple Makefile demo for test_aco_synopsis.c. A full functional makefile (also including the test suites) will come with the release of v1.3.0.

[elfring]

I propose to invest development resources more in better build scripts than in a questionable make file.

[hnes]

Of course, we will. That Makefile is just temporary and will be substituted in the future with our formal build system generator. I should have commented on it clearly.

[elfring]

How do you think about to avoid intermediate work if you became convinced that other development approaches will provide better functionality?

[hnes]

Sometimes, such intermediate work is unavoidable, but I'll try to reduce it. Yes, if there are better approaches and also cost little, absolutely I'll follow it.

On Fri, Jul 13, 2018 at 8:36 PM, Markus Elfring notifications@github.com wrote:

How do you think about to avoid intermediate work if you became convinced that other development approaches will provide better functionality?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/hnes/libaco/issues/5#issuecomment-404821072, or mute the thread https://github.com/notifications/unsubscribe-auth/AHMtkyVk8ZApr7UDe8qjo8VaVlnlIt7_ks5uGJRZgaJpZM4VGYYB .

[ddengster]

Don't agree with using an overly-complex build system. A simple makefile should be more than enough.

Check out this code philosophy; I think your code is so tiny it fits right in. https://github.com/nothings/single_file_libs

[hnes]

Thank you very much for your kindly advice, @ddengster.

In the future, even we decide to add some build system generator, that would be only limited to the build of the test suites. There would be no such static or shared library makefile for libaco (the reason is described in the 2nd comment of this thread) unless there are some very strong benefits.

[elfring]

Is a build approach like “GNU Libtool” another incentive for further evolution in this software area?

[techbech]

Any updates on this @hnes ? :slightly_smiling_face: