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

Would a pull request supporting CMake builds be accepted? #186

Open
jonesmz opened this issue Jun 24, 2021 · 5 comments
Open

Would a pull request supporting CMake builds be accepted? #186

jonesmz opened this issue Jun 24, 2021 · 5 comments
Labels
build Related to compiling, linking, packaging and distribution.

Comments

@jonesmz
Copy link

jonesmz commented Jun 24, 2021

As the title says.

I'm willing to make a PR that adds CMake support, but don't want to spend the time if it'll be rejected.

@jevolk
Copy link
Member

jevolk commented Jun 24, 2021

If you actually put in the time and effort to make this work, and it does the job fair and completely -- it would not be rejected. I would further hope it replaces autotools rather than both existing side-by-side.

However, it would be fair to state why you'd like to embark on this. What is the current problem(s)? How does CMake fix said problem(s)? Why does autotools fall short? Is it efficient to overhaul the whole build system for this reason?

If you can answer these questions, you might find yourself convinced it's not quite worth it. Otherwise you'll be the one convincing me!

@jevolk jevolk added the build Related to compiling, linking, packaging and distribution. label Jun 24, 2021
@jonesmz
Copy link
Author

jonesmz commented Jun 24, 2021

My interest is simply as an educational exercise about the Construct project as a potential avenue to become a contributor.

I have many years of advanced CMake experience, but very little experience with autotools that wasn't just frustration and finger-crossing.

@jevolk
Copy link
Member

jevolk commented Jun 24, 2021

There are infinite paths to becoming a contributor; they don't need to fight the traffic on the avenues to get through.

There is still a lot about the build system which remains opaque to me after all these years. I've gotten by 90% of the time by copy-paste-tweaking and google searches. The remaining 10% required some effort and hacking. During that time I always curse at the macros and this POSIX shell DSL, to which I've erroneously introduced non-standard bash'isms (see #88 ).

The best build experience I've ever had came from SCons -- specifically after I hacked it for fast invocation. SCons gives us the full power of python. Anything is possible and everything is intuitive. The characteristics of the build could depend on tomorrow's weather forecast -- anything, and all implemented by 10 lines of python copy-pasted from stackoverflow, etc.

This example though wasn't packaged and shipped as a FOSS project in a POSIX server environment. AFAICT autotools is the industry standard for this type of project, and people seem to know it quite well, certainly better than me, when they show up out of the woodwork.

@nigels-com
Copy link

cmake is essentially the industry standard, from a C++ point of view.
I'd be much happier to deal with a project using cmake than autotools, to be honest.
Having said that, cmake is part of my job and not something I'd want to spent discretionary time on either.

Perhaps take these remarks as coming from a fellow open source maintainer, you'll get bugged and questioned about cmake until it's there and working. The internet has spoken.

@loonycyborg
Copy link

FWIW I could make an SConstruct file for it. Fits project's name too..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Related to compiling, linking, packaging and distribution.
Projects
None yet
Development

No branches or pull requests

4 participants