Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
Hi,

Maybe ... I examine the help of wlink (.ie. "wlink ?") with the two binaries in C:\WATCOM\binnt and in C:\WATCOM\binnt64, and the directive "file" before " object files in the command line of linker seems mandatory with the twice.
But, this is ... search of perfection,   :D ...
After these exchanges, I'm proud to announce all my generation on Windows 11, Debug/Release, 32 bits or 64 bits, with all compilers (Borland, GCC (many configurations), CLANG (many configurations), WATCOM, MSVC, DMC, LCC, Pelles C) are treated correctly with CB in the same project. Consult https://github.com/tdechaize/Lesson01 for example.
Many thank's of devlopers and you.

Thierry D.
2
Hello Speedreadersteve.

Initially you wrote:
Quote
... since I compiled a 500+ line file - mostly of comments and ~200 lines code, a lot of statements in main() - it's taken a consistent 6 seconds. ...

Please keep in mind that the compiler is not only processing the code lines written by you but all code lines in the header-files you have included. And this may result in your issue by just small changes in your self written code.

Before the compiler starts the translation of the file the preprocessor will extend your own code.
  • Every include line will be replaced by the complete content of the included file. And if an included file contains include-commands by itself the preprocessor is replacing  this include commands by the corresponding file content also.
  • If you use preprocessor-defines (maybe provided by an used library) the corresponding CONSTANTS and MACROS, used in your code, will be replaced by the code used while the definition with their #define statement.
  • This is just a very rough and general description. But I hope you understand that already the use of the #include and #define directives  could increase the workload of the complier even your own code my just contain less then 10 lines.

Especially today many modern libraries for example provided by the boost-project are based on meta-programming. But you may already have a similar effect if you just use a STL (Standard Template Library) provided by a standard C++ build suite.
  • This means that the library may contain just header-files, which define templates only.  This means before actively using this libraries, they could not be build, since especially data-types are just defined by placeholders.
  • By using them you define the specific data-type for each placeholder in your own code and based on this definition the compiler is now creating the final code of the library object you want to use.
  • This is increasing the workload of your compiler and you could compare it with the preprocessor workload.

Furthermore, if you use a meta-programming based library or a STL in a header, every cpp file that is including this header directly or indirectly will be affected by a combination of both effects.

I hope that this will give you an idea how you could blow up the build effort just by adding 1 or 2 lines of code.

You may reduce your resulting problems by a pre-compilation of your header files as suggested by the other discussion participants. Thus, please follow their advises.

However, you may already limit the initial root-cause by a refactoring of your software design.
  • Limit the dependencies between your sources as far as possible. Whenever you are able to eliminate the use of an other module or class you could eliminate the corresponding including of a header.
  • Split big header files when ever possible. If you have a header that will be included by 10 other files but every including file is only using 10% of the headers content, try to split your header in 10 smaller headers with the goal that every using source is just including one new smaller header with the needed information.
  • If possible include headers in cpp files but not in other headers to reduce indirect includes.

Do you already use Doxygen? together with the tool Dot from Graphviz ? This tool is able to provide you for every of your source-file an include graph that shows you not only the direct but the indirect included files. This graphs will help you to detect the most complex include dependencies.

Best regards,
                     Eckard Klotz.

PS.: Dear forum admin. I know, actually this is not a programming discussion. But I face very often similar issues in my own projects and had to learn over the time that the reason is not the tool (Code::Blocks, build-suite, ...) but in the most cases the software design. Thus I hope sharing my experiences will help to reduce the users frustration a little bit.
3
Development / Re: UI for project globs aka automatic source directories
« Last post by BlueHazzard on Yesterday at 04:44:11 pm »
Thank you! Fixed in trunk
4
Development / Re: UI for project globs aka automatic source directories
« Last post by Miguel Gimenez on Yesterday at 10:51:44 am »
I get this warnings/errors when trying to compile in MSW-32 bits:
Code
projectfile.h||In constructor 'ProjectFile::ProjectFile(cbProject*)':|
projectfile.h|237|warning: 'ProjectFile::project' will be initialized after [-Wreorder]|
projectfile.h|195|warning:   'GlobId ProjectFile::globId' [-Wreorder]|
projectfile.cpp|26|warning:   when initialized here [-Wreorder]|

projectmanagerui.o||In function `ZN16ProjectManagerUI13OnManageGlobsER14wxCommandEvent':|
C:\Codeblocks\src\src\projectmanagerui.cpp|1657|undefined reference to `ManageGlobsDlg::ManageGlobsDlg(cbProject*, wxWindow*, int, wxPoint const&, wxSize const&)'|
C:\Codeblocks\src\src\projectmanagerui.cpp|1657|undefined reference to `ManageGlobsDlg::~ManageGlobsDlg()'|
C:\Codeblocks\src\src\projectmanagerui.cpp|1657|undefined reference to `ManageGlobsDlg::~ManageGlobsDlg()'|
The undefined references appear because you added the new files to all projects but CodeBlocks_wx32.cbp. I have attached a patch for this part.
5
Development / Project files for 'wx-3.1.x', 'wx-3.2.x' and unix do not exist
« Last post by LETARTARE on Yesterday at 10:39:05 am »
I use 'OpenSuse::Leap-15.4' which provides 'wx-3.2.1' and 'gtk-3'
But the project files for 'Linux' are missing for 'wx-3.1.x' and 'wx-3.2.x'.
I had provided a fix with the ticket https://sourceforge.net/p/codeblocks/tickets/1349/, but it should be checked.
6
You have to make a rebuild to see the build process. This is all described in the link above...
1) Load your project
2) Hit Build->Rebuild
3) Copy everything from the build log
4) paste it here and using the # symbol button in the forum editor toolbar, not the keyboard. Then there should appear code tags in the editor and between there paste the log
7
That's what I took from the "build log" tab at the bottom.  Is there another place?

#
-------------- Build file: "no target" in "no project" (compiler: unknown)---------------

Checking for existence: D:\Documents\C++ Scripts\Hacks\Garbage throwaway hacks\garbage.exe
Executing: '"C:\Program Files\CodeBlocks/cb_console_runner.exe" "D:\Documents\C++ Scripts\Hacks\Garbage throwaway hacks\garbage.exe"' (in 'D:\Documents\C++ Scripts\Hacks\Garbage throwaway hacks')
Set variable: PATH=C:\Program Files (x86)\CodeBlocks\MinGW\bin;C:\Program Files (x86)\CodeBlocks\MinGW;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\MinGW\bin;C:\Program Files\dotnet;C:\Program Files\Git\cmd;C:\Users\User\AppData\Local\Microsoft\WindowsApps;C:\Users\User\AppData\Roaming\npm;C:\Program Files (x86)\FAHClient;A:\Apps\SocketeQ\windowsandroid_root\system\bin;A:\Apps\SocketeQ\windowsandroid_root\system\lib;C:\Users\User\AppData\Local\atom\bin;C:\Users\User\.dotnet\tools
Process terminated with status -1073741510 (0 minute(s), 9 second(s))
#
8
Development / UI for project globs aka automatic source directories
« Last post by BlueHazzard on Yesterday at 12:14:53 am »
Hi,
today i pushed (r13191) a UI for project globs aka automatic source directories.
This adds
+ an UI for the user to easy enter directories and specify if they should be added recursively and with file masks (found under the menu Project->Automatic source paths)
+ a logic based on wxFileSystemWatcher that watches the above added directories for file changes and adds and removes the file as they are added and removed from the file system
+ a rudimentary script binding

BEWARE: this changes behaviour of old file globs, that was only accessible when editing the project file directly.
The old implementation (loading the directories only on project load, and not adding them in the project file directly) made problems with code completion and compiler settings ecc...
I think this implementation is a lot better, but it changes the project file every time a file is added in the directory (as a makefile would).

i worked for this a while ago, obfuscated made some reviews and was ok with it, but because the wxFileSystemWatcher was not available on all platforms in wx2.8 this work was lost. Now that we are on wx3.0 a was thinking to add this to trunk.
Any comments are welcome.
thank you!
9
Fixed in trunk, thank you.
10
Plugins development / Re: Fix to build wxsDateTimePickerCtrl on Linux
« Last post by BlueHazzard on February 02, 2023, 11:07:04 pm »
Fixed in  r13189
Thank you!
Pages: [1] 2 3 4 5 6 ... 10