Compilation of C::B on Ubuntu 20.04 (current LTS) using autotools works, but is is cumbersome for developing. I tried compiling C::B using C::B, but found diverse problems:
missing includes and libraries in main project
hundreds of warnings in plugins
lack of homogeinity in compiling options
warnings about incompatible gch (not fixed by the path)
I do not know if somebody uses this method, but I doubt it.
The attached patch makes C::B compilable with C::B, but before commiting it I would like to hear opinions about possible side effects on other distributions (specially Mint and Debian).
I found that building on LM 20.3 and Xubuntu 20.04 was very difficult not because of the issues being fixed, but that the docs I could find were way date for using the autotools, BUT creating the Debian deb files was crazy as:
- the info in the source is not correct
- there is no info on the wiki
- the forum has bit here and there, but not in one spot
I have created the following docs to update the build process files in the src:
Readme_Build_Debian_deb_packages.txt
Readme_Build_Linux_by_Makefile.txt
Readme_Build_Linux_by_Workspace.txt
Readme_Build_Windows_by_Workspace.txt
I need to check the docs against Bluehazzard's https://github.com/bluehazzard/codeblocks_sf/wiki pages and borrow info I have not put in the docs.
I still need to produce docs on creating a nightly and release build as these require version and other src changes. I will base these docs on the existing README.release file.
The docs will be submitted as part of ticket 1121 after 1163 & 1172 & 1179 are completed.
As for checking the changes hopefully I can get to look at them later today (it's 8:30AM Sydney time).
Attached are the updated docs in case you want to look at them of need help on building the deb files.
Last edit: Andrew Cottrell 2022-01-19
I have done a code review and the following is my feedback:
1) AutoVersioning - compiler has both -fPIC and -DPIC. The following files also have -DPIC. Something to look at and see if it is needed
src\plugins\contrib\AutoVersioning\AutoVersioning_wx30-unix.cbp
src\plugins\contrib\BrowseTracker\BrowseTracker_wx30-unix.cbp
src\plugins\contrib\regex_testbed\RegExTestbed_wx30-unix.cbp
src\tools\cb_share_config\cb_share_config_wx30-unix.cbp
src\tools\cbp2make\cbp2make_wx30-unix.cbp
2) byogames - has additional <fwddecl="0" i18n="1"> (text between <>) added to the resources entry. Is this right?
3) CodeBlocks_wx30-unix.cbp - pkg-config should be like $(WX_CONFIG) in that you can change teh GTk version supported via environment variable(s)
as such if you change the gtk+-<version> so that the <version> is an environment variable it will then allow users
to change between GTk2 and GTK3 in "theory"in the one area, being the environment variables instead of in a number of spots.
Theory and the real world may prove to be different as time progresses or too difficult. I have made this change in
my code, but have not built against GTK2 yet.
4) CodeBlocks_wx30-unix.cbp - compiler options have both -std=c90 and -std=c++11. Is this allowed and valid? I have no idea on this one.
5) With the removal of allot of blank elements if someone saves the project file will these be added again? If so then before or soon
after merging the project saving code should be modded to only save non blank elements so they are not added in again in the future.
6) With the sorting of sub sections in the <extensions> child elements will the existing save code sort it revert it? If it sorts it
then okay, but if it does not then the code should sort it so the changes are not reverted in the future.
7) wxSmithAui_wx30-unix.cbp - the -std=c++11 line has not been moved like other files. Is this right? </extensions></version></version></fwddecl="0">
I have not done a build yet, but should be able to do this in the next 2 to 3 hours. I got stuck today getting Ubuntu bash and GUI apps working on Windows 10 21H2 WSL2 (not W11). This makes it easier for access files and sharing files.
The testing below was done using a Ubuntu 20.04 on/in a Windows 10 21H2 environment.
A) I rebuild the CodeBlocks_wx30-unix.workspace using SVN with the patch applied then I gave up on building it after 90 minutes as it was still building.
B) If I rebuild the CodeBlocks_wx30-unix.workspace using SVN with the patch applied and the hacked /usr/lib/x86_64-linux-gnu/wx/config/gtk3-unicode-3.0 then the following is the rebuild output final result:
=== Build finished: 0 error(s), 470 warning(s) (3 minute(s), 48 second(s)) ===
C) If I rebuild using my source tree using CodeBlocks_wx30-unix.workspace with the hacked /usr/lib/x86_64-linux-gnu/wx/config/gtk3-unicode-3.0 then the following is the rebuild output final result:
=== Build finished: 0 error(s), 526 warning(s) (4 minute(s), 11 second(s)) ===
So the build time of A) is IMHO unacceptable even with the changes. Based on my testing and work done over the last week I would expect LM to be the same as Ubuntu 20.04 w.r.t. time percentage differences. When I built on Virtual Box LM 20.3 guest option C) took just over 6 minutes.
ow long does it take you to build the using CodeBlocks_wx30-unix.workspace?
How many warnings do you get?
Even with these issues please commit the code once you look at the issues in the previous post as it does not make it worse than before and makes the project files more consistent and therefore better.
Thank you for reviewing:
- Polishing superfluous options (like -DPIC) can be done in a second stage.
- Details about internal layout of the CBP (p.e. line ordering) are not relevant as long as you edit the CBP file using Build Options instead of a text editor, in fact the docs say that CBP files should be considered as binary data.
- Simultaneous usage of -std=c90 and -std=c++11 is valid, one will be used for C files and the other for CPP ones.
- Selection of GTK2 or GTK3 can be done in a second stage, but IMHO GTK2 should be considered obsolete. Also, probably selection may be made automatic using information from wxWidgets.
A full rebuild of the workspace lasted 4'6'' and gave 113 warnings, most about invalid pch and unused variables. I am using gcc 9, wxWidgets 3.0.4 and GTK3.
I will commit the proposed patch in a while.
Applied in [r12664].
Related
Commit: [r12664]
as described in the other ticket, I think -Wextra should return, this is sticking our head in the ground and lowering the quality checks on the code base
-Wextra is not in the MSW projects, and it generates a lot of picky warnings that can hide a dangerous warning. Some of them have difficult fix, for example each call to Connect() using wxSmith's generated code produce a warning.
Anyway, if you think it must be there say so and I will readd it. What about MSW projects?.
After enabling -Wextra in CodeBlocks_wx31.cbp, I get 6369 warnings (compiling with MinGW-w64).