Switch to a modern build system [$30 awarded] #404
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/znc#404
Reference in new issue
Block a user
Please switch to a modern and maintainable build system. I don't care which exact build system it is, as long as it doesn't involve 90's style hand-written makefiles. I've proposed CMake (https://github.com/znc/znc/pull/648) in the past.
--- The **[$30 bounty](https://www.bountysource.com/issues/5375326-switch-to-a-modern-build-system?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on this issue has been claimed at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).I find premake a pretty decent one, even tough if the current 4.x one lacks some special make support like install, uninstall and clean events, tough they are added for 5.x.
But that's just a personal preference of mine because I like lua~
If the build system works well then an end-user doesn't have to bother with it, no?
And anope seems to be doing just fine with cmake so there's that.
👍 for cmake. Most of other things I compile from source are also using cmake.
@neico Does premake have support for finding external dependencies?
What exactly do you mean?
Something like this: http://industriousone.com/links-0 ?
ZNC has quite a few optional external library dependencies such as ICU, OpenSSL, Zlib and Cyrus SASL to name a few. What I meant is checking whether such libraries and their development headers are available, and then providing the appropriate build flags for those.
But... you close #648 ?
On topic, a few years ago I started a branch for switching to https://code.google.com/p/waf/ but never finished it. As opposed to cmake, waf requires only python installed.
What do you mean by control over exported symbols?
__declspec(dllexport)?@jpnurmi I guess you can write that with the help of http://industriousone.com/osfindlib and all those other os.* functions, it's rather flexible on how things should work, I can't help with that much as I didn't need to use it to that extend yet.
My build scripts are rather simple: https://gitlitio.us/neico/kvedit/blob/master/build/premake4.lua
It wasn't worth the time and effort. It was leading nowhere.
👍
I'm not talking about MSVC. I'm talking about making symbols hidden by default, only explicitly exported symbols visible outside. Modules would get linking errors if they tried to reference private classes that are not exported. No idea if that's even possible with the current structure.
That's what we're doing now for modules... Every module exports only one symbol:
ZNCModInfo().It's done because several modules might have the same class name, and they would conflict (it happened before).
In GCC it's spelled like
__attribute__((__visibility__("default")))and-fvisibility=hidden. Well, take a look at the top of Modules.h👍 for CMake.
That is worded as if that is supposed to be an advantage but it is not. That is a pretty heavy dependency for the build infrastructure and is undesirable by packagers.
I can understand why it's not very desirable by packagers. But for end users, who don't have root access on the system (no apt-get, no emerge, etc), and want to install a program from source, it's not a problem. Python is installed by default everywhere, just like bash (*). CMake is installed by default in far fewer distros.
I'm not saying that we must switch to waf (or any other python based build system), it's just an option to consider.
(*) almost everywhere, some distros use dash instead :)
Many distros also don't have Autotools or a C++ compiler installed by default. If development tools, headers and libraries are installed in general, the odds for CMake aren't that bad these days.
http://www.cmake.org/Wiki/CMake/Projects
That is an assumption that is not even close to being true.
Python has been part of LSB for a while now.
Doesn't change what I said and is mainly irrelevant.
I absolutely agree with brad0 python is not everywhere, and linux is not UNIX, there is a number of other NIXes out there like HP-UX and those almost never heard word "python" I could try to help set up CMake I've done that multiple times for mid-sized projects (400+ source code files, multiple targets, libs etc)
In the end, it's all about the convenience of ZNC development. Switching to a modern build system goes in the same category with C++11. Not strictly needed, but simply makes the lives of ZNC developers easier. While not necessarily directly benefiting the users, this kind of changes are the ones that pave the road for new amazing ZNC features. Happy developers tend to be more creative than frustrated ones.
Been there, done that... #648
To me, personally, http://www.cmake.org/Wiki/CMake_Editors_Support (*) alone would be worth the change. I use Qt Creator for all my development work. CMake support would give me a proper project tree.
*) seems to be missing CLion so add that promising C++ IDE on the list
Well, not exactly the same, but almost.
I agree.
And every time I needed to change something in the build system (especially, in Makefile part), I've been very unhappy, it didn't work well, and I ended up with writing various ugly hacks.