Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Will C::B ever move to Git w/ Github or Gitlab?

<< < (6/6)

oBFusCATed:
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.

oBFusCATed:
Also it would be best to start a separate topic about the cmake stuff when you have something that works...

Lazauya:

--- Quote from: oBFusCATed on May 12, 2021, 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. :)

--- End quote ---

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.)


--- Quote from: oBFusCATed on May 12, 2021, 07:32:49 pm ---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.

--- End quote ---

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


--- Quote from: oBFusCATed on May 12, 2021, 07:32:49 pm ---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.

--- End quote ---

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.

oBFusCATed:

--- Quote from: Lazauya on May 12, 2021, 08:01:51 pm ---So what DOES moving to Git depend on?

--- End quote ---
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.


--- Quote from: Lazauya on May 12, 2021, 08:01:51 pm --- I want to do THAT along ...

--- End quote ---
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.


--- Quote from: Lazauya on May 12, 2021, 08:01:51 pm ---I like full IDE's and CB. I really don't want this project to be a relic any longer.

--- End quote ---
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...


--- Quote from: Lazauya on May 12, 2021, 08:01:51 pm ---I don't think bug fixes and QOL improvements will fix that, I think it needs more radical change. But that's just me.

--- End quote ---
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.

Lazauya:

--- Quote from: oBFusCATed on May 12, 2021, 08:20:40 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...

--- End quote ---

Looks like I got my laundry list. I'll get to work.

Navigation

[0] Message Index

[*] Previous page

Go to full version