Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
Using Code::Blocks / Re: Undefined reference
« Last post by jury on Today at 10:57:05 pm »
this is strange... have you installed python 2.7?

Yes. I have python2.7-devel installed fine. When building this project from command line it finds python2.7 and the build process goes OK.

Why is it that nearly every [NEW] poster posts from "Build Messages" instead of "Build Log"?

I do not understand this. What I have presented is "Build Log". I clicked "Build log" tab in Code::Blocks, then pressed Ctrl-a and from right-button menu I selected "Copy selection to clipboard".
2
Development / Re: Will C::B ever move to Git w/ Github or Gitlab?
« Last post by Lazauya on Today at 10:26:52 pm »
So you think that switching to git magically would make the debugger plugin to actually work in the real world?
Or it will auto integrate something like LSP to make CC support C++2099?
Or it will make the build system to utilize modern mutli-core cpus?
Or it will add better cmake/meson support...

Looks like I got my laundry list. I'll get to work.
3
Nightly builds / Re: The 11 May 2021 build (12446) is out.
« Last post by oBFusCATed on Today at 09:46:01 pm »
4
Development / Re: Will C::B ever move to Git w/ Github or Gitlab?
« Last post by oBFusCATed on Today at 08:20:40 pm »
So what DOES moving to Git depend on?
It depends on the development team deciding that moving to git, github, gitlab or anything like that is worth the effort and it is beneficial.

I want to do THAT along ...
It is not up to you to do that or to decide it at. At least at the moment.
If you contribute enough good work you can request being added to the development team.

I like full IDE's and CB. I really don't want this project to be a relic any longer.
It will stop being a relic if people work more on it. Your proposition is that the use of svn/sf.net stops quality work being contributed.
I don't believe this to be true and it is hard to measure it, so it is for you hard to prove it. And we're actually on github and we're actually using git...

I don't think bug fixes and QOL improvements will fix that, I think it needs more radical change. But that's just me.
So you think that switching to git magically would make the debugger plugin to actually work in the real world?
Or it will auto integrate something like LSP to make CC support C++2099?
Or it will make the build system to utilize modern mutli-core cpus?
Or it will add better cmake/meson support...

I'm out of this topic. If you want to discuss your cmake contribution please start new one.
5
Development / Re: Will C::B ever move to Git w/ Github or Gitlab?
« Last post by Lazauya on Today at 08:01:51 pm »
If you delete the autotools build system we don't have the official/current build system (used to make linux packages) to compare if the cmake system is correct or not.
So deleting it as a first step is wrong, at least if your goal is to be able to merge your branch in the official repo.
So if you want to have a chance of the work being integrated in the official repo, please leave autotools intact. Deleting it is the easiest thing.
On the other hand if you just want to play with cmake and then drop the thing after a while then it is fine to delete autotools or do whatever you want. :)

Like I said before, this is a non-issue. Adding back autotools is simple. I'll add it back before I even try merging to master, of course. (Or move the CMake files to a clone of the original, whatever works better in the end.)

Also I'm not sure I like the idea of config.h.in. I'd rather not use it. The internal C::B build system doesn't use it and we're fine, without it.

Perfect. Then I'll just remove it altogether in my next commit.

p.s. The switch to git doesn't depend on using cmake or not, these two are orthogonal. Mentioning this to prevent some possible confusion.

So what DOES moving to Git depend on? I want to do THAT along with moving to CMake; I think using CMake is a very necessary modernization, and so I will continue until it's as feature complete as I can make it. However, I think moving the project to a more modern platform like Github, Gitlab, or even an org-maintained Git repo (like what Blender has) is a must. I like full IDE's and CB. I really don't want this project to be a relic any longer. I don't think bug fixes and QOL improvements will fix that, I think it needs more radical change. But that's just me.
6
Development / Re: Will C::B ever move to Git w/ Github or Gitlab?
« Last post by oBFusCATed on Today at 07:46:53 pm »
Also it would be best to start a separate topic about the cmake stuff when you have something that works...
7
Development / Re: Will C::B ever move to Git w/ Github or Gitlab?
« Last post by oBFusCATed on Today at 07:32:49 pm »
If you delete the autotools build system we don't have the official/current build system (used to make linux packages) to compare if the cmake system is correct or not.
So deleting it as a first step is wrong, at least if your goal is to be able to merge your branch in the official repo.
So if you want to have a chance of the work being integrated in the official repo, please leave autotools intact. Deleting it is the easiest thing.
On the other hand if you just want to play with cmake and then drop the thing after a while then it is fine to delete autotools or do whatever you want. :)

Also I'm not sure I like the idea of config.h.in. I'd rather not use it. The internal C::B build system doesn't use it and we're fine, without it.

p.s. The switch to git doesn't depend on using cmake or not, these two are orthogonal. Mentioning this to prevent some possible confusion.
p.p.s. It is a requirement that you preserve the internal build system, too.
8
Development / Re: Will C::B ever move to Git w/ Github or Gitlab?
« Last post by Lazauya on Today at 06:06:30 pm »
Deleting autotools as a first step is the wrong move...

I don't have the authority to delete anything from any official repositories. If you're referencing how it's gone from my branch, that was just for making the conversion easier. The only thing thay would be incompatible would be the config.h.in, so maintaining the legacy build system alongside cmake should be simple enough.

In any case, what would be the first step? What can I do to make this happen? You said that you you don't want to spend your time doing it, but I do.
9
Help / Re: Can't debug even a Hello world program
« Last post by oBFusCATed on Today at 04:25:53 pm »
The debugger shipped with 20.03 is known to be broken.
Search the forum for topics about working debuggers...
10
Using Code::Blocks / Re: Adding include directory
« Last post by oBFusCATed on Today at 04:24:46 pm »
What do you mean with "It is a bug"? A mistake?
I mean that if the "open include file" feature of the IDE doesn't work, but compilation from the IDE works, then it is most probably a bug in the IDE and it should be possible to fix it.
Pages: [1] 2 3 4 5 6 ... 10