Why package 3rd party libs vs. using their packaged versions?

[yurivict]

[jcoffland]

Because managing them as separate dependencies is a PITA. I've done it both ways and it's is far easier to build the projects that depend on cbang with most of the 3rd party packages build-in. Especially on Windows. Not so much with Debian or FreeBSD.

[yurivict]

Yes, it's mostly on Windows. Other platforms need a switch to use packaged versions.

[jcoffland]

You would have to give me a really good reason to change it. It works well the way it is for the builds I'm doing. Maintaining both ways of building the software adds complication.

[yurivict]

I can't create a cbang port because it only contains bundled libraries. This is against the policy of not using bundled libs. The reasons for this policy:

1. Security: security issues are much more difficult to patch when the same code is built into many projects
2. Disk size: This increases the disk size of packages
3. Patches: It assumes that all projects are easy to build everywhere, while this is only true on linux, and usually not on BSDs, where patches are required
4. Scaleability: Bundling is obviously unscaleable: if many/all projects would take this approach, each low level library would be included exponentially many times

[jcoffland]

Are you ultimately trying to create a port of CAMotics? If so, libevent, libyaml, re2 and sqlite3 could just be disabled. They are not used by CAMoitcs. The above arguments don't really apply to boost since it's 99% header files. That leaves bzip2, expat and zlib. It would not be too difficult to configure these to use external versions. It might even be possible with exsiting configuration options.

[yurivict]

Ok, thanks, I will see if it builds.

[artyom-poptsov]

Hello,

first of all, thank you for your work on CAMotics -- we really need more good free CNC-related software.

But!

I'm trying to package CAMotics for GNU Guix; I basically managed to build cbang (I had to patch the tests and some build programs to make them run with Python 3 -- see commit history for my avp-add-cbang branch for details), but the main issue here is that you've included lots of code from other libraries. That's not looking good for several reasons:

1. There are a few licenses that cover cbang due to the code cherry-picking, so to say. Such "licensing pluralism" could (and probably will) embarrass a user (like me) who takes the licensing questions seriously.
2. If someone find a bug in an original library (let's say in libevent) you'll have to track it down and patch it in cbang.
3. It makes hard to track down the dependencies of any project that uses cbang for functional package managers like Nix or GNU Guix.
4. If I send my patch with cbang package to GNU Guix upstream and the maintainers accept it (which is unlikely I think), we could trick some users to use cbang for their project which in turn will make the things even worse (due to problems 1-3.)

To wrap up all that I mentioned above, could you please make an option to de-couple CAMotics from cbang library? Also I see you mentioned in the issue that one could build CAMotics without cbang but as far as I can see there's no mention of it in the docs (probably I overlooked something though.)

Thanks,
avp

[jcoffland]

CAMotics is heavily dependent on C!. That's unlikely to change. The only reason cbang includes third party libraries is to make it easier to compile. Previously, compiling cbang on Windows was a huge pain. Now it's only an minor pain. It would be possible to alter the build system to allow it to link to external versions of these same libraries but it's just not worth the maintenance effort. See my comments above. But hey, it's free and you're welcome to do what you like with it within the confines of the license.