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

Guide for building C::B on Linux request due to wiki 502 error

<< < (4/5) > >>

cacb:

--- Quote from: AndrewCot on November 20, 2021, 11:57:12 pm ---Saying that SF has GIT support, so the first thing is for someone to figure out how GIT in SF works if you are already are using SVN see if you enable/setup/config GIT in SF what how do the SVN and GIT interact and will this enable usage of both GIT or SVN and the changes automatically get applied to the other. I have no idea if this is possible or not or how SF version control works under the hood.

--- End quote ---

I tried to access the SF SVN repo with SF's claimed git support, but I couldn't make it work. Maybe that's just me, but anyway. So instead I installed the support for svn in git (I use Kubuntu 20.04 for this):


--- Code: ---sudo apt-get install git-svn
git svn clone https://svn.code.sf.net/p/codeblocks/code/trunk codeblocks-code
--- End code ---
Clearly, if you research git-svn it is possible to feed back updates to SVN repos from git svn, but I think it would be much easier if the main C::B repo was a git repo, on github or somewhere else.

By the way, I can now see that the latest SF SVN updates to C::B from a few hours ago have been successfully replicated in my github mirror, so it seems to be working as intended.

cacb:

--- Quote from: AndrewCot on November 21, 2021, 12:00:49 am ---@caab your GITHUB repo like OBF's does NOT include the SVN referenced Fortran repo. Be aware that as such if you use it as it is it will not build due to the missing Fortran plugin source.

--- End quote ---

Where is the Fortran repo? How does this work with SVN? My repo is a direct copy of SVN trunk. Is there some mechanism in svn that clones an external repo similar to git submodule?

If there is anything to fix, as a minimum I need some pointers.

cacb:

--- Quote from: cacb on November 21, 2021, 07:49:18 am ---If there is anything to fix, as a minimum I need some pointers.

--- End quote ---

Actually, I don't understand the claim that the Fortran plugin is missing. I just tested C::B built yesterday from my github mirror, where supposedly the Fortran plugin is missing, but I was able to compile and build a Fortran program just fine. All I had to do was to install gfortran (under Kubuntu 20.04)


--- Code: ---sudo apt-get install gfortran
--- End code ---

In C::B I did

--- Code: ---File -> New Project ... Fortran Application
--- End code ---
I chose the "GNU Fortran Compiler" and  it worked, see attached screenshot.

Is this because I have a default.conf from before or what? As far as I can tell Fortran works just fine.



AndrewCot:
Sorry, but I am not a SVN user, apart from fetching C::B from SF. As such some of the SVN info below I only just looked up.

1. The fortran repo is on SF
    https://sourceforge.net/projects/cbfortran/
   
    The CBFortan plugin home page is:
        https://cbfortran.sourceforge.io/
   On the page the dev section has the following:
The major part, which makes C::B IDE useful for Fortran, is FortranProject plugin. This plugin has a separate project for development on Sourceforge. There you can download latest source code directly from svn.
     
The fortran plugin SVN repo is:
    http://svn.code.sf.net/p/fortranproject/code/trunk/

2. The plugin references can be found by searching for "FortranProject" the src/*.workspace files and in the src\plugins\contrib\Makefile.am. Be aware that ticket 1155 restores the Fortran plugin in the workspace files.

3. I may be completely wrong, but you are correct in that you do not need the plugin to compile a fortran program. It adds a Fortran menu and options that make it easier. Attached is


4. When I browse the SF SVN C::B repo using Tortoise SVN on Windows the src\plugins\contrib\FortranProject as a little arrow on the folder icon on the bottom left. The PythonPlugns also has the same arrow, so it may also be missing.
 When I click on the src\plugins\contrib\FortranProject directory the URL in the TortoiseSVN broser shows https://svn.code.sf.net/p/fortranproject/code/trunk
 When I click on the src\plugins\contrib\PythonPlugns directory the URL in the TortoiseSVN broser shows https://github.com/spillz/codeblocks-python/trunk

My conclusion is like GIT sub modules SVN can also reference other repos. For SVN externals checkout the following https://svnbook.red-bean.com/en/1.0/ch07s03.html for info on it.

5. The source that are used to create the Windows installer are in the following SF repo:
    http://svn.code.sf.net/p/codeblocks/code/setup
   This SVn repo will also need to be converted to GIT.  See ticket 1119 and https://github.com/acotty/codeblocks_sf/tree/AC-WindowInstallerUpgrade as I have worked on the installer and moved it into the main repo as the scripts to build the Debian are in the main repo so why shouldn't the Windows files. So it may be easier to move/update the installer. I am still waiting for feedback from MortenMacFly  as per the following thread https://forums.codeblocks.org/index.php/topic,24603.0.html

6. The source for the documentation needed to create the docs are in the following SF repo:
    http://svn.code.sf.net/p/codeblocks/code/docs
   This SVN repo will also need to be converted to GIT. It is not easy to generate the docs, see https://forums.codeblocks.org/index.php/topic,23614.msg160976.html#msg160976 for info/help/tips/tricks etc....

7. There are other SF repo's under the following folder that are very old and as such may not be of any use
     http://svn.code.sf.net/p/codeblocks/code/

AndrewCot:
Before you start this have a look at the following plugin:
    https://github.com/loandr/GitBlocks

And get a few of the long term devs on board otherwise you will be doing work for nothing and based on previous posts this may not flay. The tickets are littered with devs who who have supplied patches and no one has looked at them and as such they wasted their time and the patches will never be incorporated. I worked on generating a list of tickets that could be closed easily and this went no where.

The reason for the changes not being incorporated has driven good devs away from the project. Once you figure out how the process works or does not work you will understand why. I would suggest you start with something smaller that could potentially make it into the truck and see how the process works and who is involved in the process.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version