Developer forums (C::B DEVELOPMENT STRICTLY!) > Contributions to C::B

Declaration of Intent

(1/3) > >>

Since none of you actually know me and I'm asking a number of stupid questions, it seems it would be a good idea to let you know why I'm here and what I'm trying to accomplish.

At the moment I find myself unemployed (so if you need a C++ guy for embedded or cloud work, please think of me) and in need of something to keep me from freaking out in between interviews. I've always thought of code::Blocks as a very underrated project that more people should know about and use.

It saddens me that support for macOS and cloud environments like Docker/Alpine has been lacking.

Of course I could whine about it endlessly, but since I have a lot of free time right now, I think I'll try to chip in.

I've already thrown up a Docker image for code:Blocks on Alpine.

I'm working on a CMAKE build script and a CI/CD environment under Bamboo. My first focus there is getting macOS to build against the latest source release. The latest macOS bundle is currently version 13.12, while Linux and Windows are an 17.12. That seems unacceptable to me. Once I have the CMAKE script functioning properly, a build should generate an MSI for Windows, DMG for macOS, RPM for CentOS, APK for Alpine, DEB/PKG for Debian/Ubuntu and I'm hoping to target Homebrew/MacPorts as well. That should make it easy to keep all the major platforms at parity.

There aren't any unit tests, it seems. Retrofitting that onto such a large application with so much history will be intense, but I'm mulling that over and hoping others will throw their hats in the ring.

The other thing I want to work on is making it easier to create plug-ins. I think plug-ins are code::Blocks' killer feature, and would love to see a thriving community developing support for just about every language, debugger and utility imaginable. I envision something like the current Docker hub, kind of an App Store for code::Blocks. It looks like about 100 plug-ins currently exist. I'd like to see that number rise to north of 10,000.

One final thing is that I'd like to chug through as many of the open bugs as possible. My hope is that if we get more people using code::Blocks, we'll also pick up more people who are willing to tackle a few open issues. There are ~400 open issues currently. That shouldn't be too hard to whittle down if we can get 30 people actively working on bugs. Call me an optimist!?!

The danger in sharing all of this is that once I get a job (please, oh please God let that be soon), contributing here will become a hobby, so I'm hoping that (a) the original code::Blocks developers will accept that I have good intentions and am not here to be a muckraker (b) that I can encourage a large number of lurkers and newbies to step up and make code::Blocks into something even more fantastic than it already is.

I don't know if you're aware but current trunk builds fine on macOS and there is also a script ( which generates the .app folder with all the needed files. The problems for the macOS builds aren't the builds themselves. Someone should start to use C::B regularly on macOS and post patches to fix the serious issues he/she encounters. The problems aren't only in C::B's sources. There many problems in wxCocoa, too.

p.s. It will be good if you can post initial version of your build system for review. For example after you make the sdk, src and plugin (excluding contrib) folders to compile and probably making ninja-build install to work.
p.p.s. cpack rpm is inferior to manually creating .spec files.
p.p.p.s. We already can make .dep and .rpm packages, not sure if you're aware...
p.p.p.p.s. It will be good if you don't open new topic for everything related to your struggles with building. You have already open 3 topics. If you post everything in a single place it will be a lot clear and a lot less typing.

Apologies for the multiple topics. Other forums complain if you discuss more than one thing.

Forgive the additional stupid questions/statements I’m about to bombard you with...

The downloads page only has a 13.12 build for macOS. Is there a reason why it hasn’t been upgraded? I know Xaviou has posted a nightly to his Google Drive, and I’m grateful for that, but most would be cautious of installing someone’s private build.

I know that you already have means to make .deb and .rpm. Just hoping that when I add support for the other packages to my CMAKE script and the CI/CD script, it will become a one step process to build everything for everyone. I agree that auto-CPACK is inferior to a hand-coded spec file, but if you point me to the .spec you’re using, I will figure out a way to keep it close.

Your posts do come across as rather hostile and discouraging but  I don’t think I’ve done anything to offend. Obviously I can’t know as much about this project as you do, being a long time user but new contributor. I certainly am not complaining about anything you guys have done; if anything, I have great respect for it. If you’d rather I go away, there are hundreds of other projects I can work on. I didn’t mean to crash your party.


--- Quote from: billus on March 15, 2019, 02:45:30 am ---The downloads page only has a 13.12 build for macOS. Is there a reason why it hasn’t been upgraded?

--- End quote ---
Because it is hardly usable...  I don't see a reason to just post any builds on the site.
Yes, people could use them and when they complain that something is not working they'll get ignored, because there isn't a person to look at their problem. Not very good situation.
BTW C::B should be available in the homebrew or macports projects as far as I know, too.

--- Quote from: billus on March 15, 2019, 02:45:30 am ---I agree that auto-CPACK is inferior to a hand-coded spec file, but if you point me to the .spec you’re using, I will figure out a way to keep it close.

--- End quote ---
Search for and look for the whole debian folder in the repo.

--- Quote from: billus on March 15, 2019, 02:45:30 am ---Your posts do come across as rather hostile and discouraging but  I don’t think I’ve done anything to offend.

--- End quote ---
I'm not trying to offend or something. If you want to work on cmake build system I cannot stop you :), I'll be happy to help. But your goals are rather big for a newcomer. You don't have an idea even if you'd like to work on codeblocks. If I were you I'd rather start with something simpler. :) To get a feel for how the project works.

I've been coding since 1975, back when 4K of ROM (much less RAM) seemed like an extravagance and you used continuation lines because punch cards and CPU time were expensive. While I'm a newcomer to the code::Blocks forum, it's likely that I've been at this much longer than you. Even when I'm dealing with a neophyte, I try to treat them with respect and decorum. Anyhow...

Care to share any insight on how the macOS build became so broken? Did dependent libraries break stuff? Humpty Dumpty was pushed, y'know. Better to start with an understanding of how it got to the current state than spend precious hours figuring it out.

A casual search indicates that code::Blocks was removed from Homebrew because the binary was 5 years old while other platforms moved forward. MacPorts warns that there's no maintainer.

Regarding big goals, it's better to aim for the moon and hit a mountain than to aim for a telephone pole and hit your own foot. Great things have never been accomplished by people who thought small.

The reception I received from the Boost.ORG folks was considerably warmer. It's not about whether you're able to stop me from trying to improve code::Blocks. I could always fork or start a new project, but I'd rather work together. Open source works best when you have many contributors, each sharing their skills to make something great for everyone. That only happens if volunteers get the warm fuzzies when they think of closing a bug on your issue list vs watching the next item on their Netflix queue. Even Linus Torvalds and Theo de Raadt have had to tame their cornholio-ness. No matter how good you are, you live and die by the vibrancy of your community.


[0] Message Index

[#] Next page

Go to full version