Recent Posts

31

Nightly builds / Re: The 01 September 2023 build (13344) is out.

« Last post by eckard_klotz on September 16, 2023, 11:36:06 am »

Hello Miguel Gimenez and Tim.S.

Please accept my apologize for my late reply.

Commits in the range 13159-13166 are not related to global variables, are you sure 13159 works and 13166 does not?

I have tested it today again.

• I can confirm, it is working with the nightly from the 22.01.2023 (13159) and it is not working with the nightly from the 29.01.2023 (13166) .
• Please refer the 2 screen shots in the attached zip-file:
  
  • CB_13159_compiler_toolchain_executables.png
  • CB_13166_compiler_toolchain_executables.png

Actually I download every nightly. But for some reasons I don't change always to the newest one.

• The attached zip-file provides a screen shot from my nightly root-directory:
  
  • NightlyFolderRoot.png
• The highlighted folders were tested by me to figure out when the issue occurred.

Based on the images; I am guessing the compiler auto detection is the problem area; instead of the global variable area.

This sounds plausible since the auto-detection warning-dialogue occurs always while starting Code::Blocks when the issue is present.

• However this was the case last year also.
• The attached zip-file provides a screen shot from my MinGW root-directory
  
  • MinGWFolderRoot.png
• As you can see, I don't use the traditional root-directory for the build-suite.
  
  • But I use an own root-directory parallel to other development tools.
  • Furthermore, I provided more than one version and flavour.
  • Thus, the auto-detection would always fail in my case.
• I use different personalities (defined in different conf-files) to choose the version and flavour to work with while starting Code::Blocks.
• Thus, I would expect that Code::Blocks is checking the paths configured in the global variables to use the build-tools configured there.
• If the tool-chain configuration is referring to global variables than Code::Blocks may check if they are validly configured.
• But if one of the global variable is not validly defined, than it is the responsibility of the user to correct its definition.
• However, Code::Blocks replaces the global variable by standard tool-names, what should not be done from my understanding.
• In my case the global variables are referring to valid build-suite locations.
• This means a valid configuration will be replaced by an invalid one.

Nevertheless, please have a nice weekend.

Best regards,
                    Eckard Klotz.

32

Using Code::Blocks / Re: I can't run a command only build target

« Last post by ollydbg on September 16, 2023, 06:07:51 am »

Please note that the "commands only" type build target has the "executable" option disable, so I can't set a executable of this target.

33

Using Code::Blocks / Re: I can't run a command only build target

« Last post by ollydbg on September 16, 2023, 05:03:14 am »

I think this issue is related:

Code::Blocks / Tickets / #1395 Compilergcc

34

Using Code::Blocks / I can't run a command only build target

« Last post by ollydbg on September 16, 2023, 04:57:28 am »

Hi, I have a build target named "MakePackage", in this target, I select its type is "command only".

In the pre-build or post-build script, I wrote the command like:

Code

cmd /c MakePackageRelease.cmd

With this command, I just copy all the exes and dlls to a specified folder.

I used this for a long time. But with the recent SVN C::B, I see this function does not work, because when I click the "run" button of the target, it will prompt

Code

[Window Title]
codeblocks.exe

[Content]
You must select a host application to "run" a commands-only target...

[OK]

Which means I have to specify a host program?

So, I believe this is a regression.

35

Plugins development / Re: GitBlocks to keep most of it working under Windows 10

« Last post by stahta01 on September 15, 2023, 11:18:49 pm »

Uhm, well... not really .

The history looks like you cherry-picked the commit, that was the worst option (does the GitHub UI even offer that option?). In general you perform a merge, for external contributions i prefer to always enforce a merge, even if like in this case a fast-forward merge would have been possible.

Also, it is kind of bad practice to create a PR from the main branch, in general you make a feature branch and create a PR from that one.

Thanks for the feedback; I will do it manually next time; I dislike git merges.

So, next time I will do a manual commit and see if it works better or it works worse.

Tim S.

36

Plugins development / Re: GitBlocks to keep most of it working under Windows 10

« Last post by sodev on September 15, 2023, 09:49:11 pm »

Uhm, well... not really .

The history looks like you cherry-picked the commit, that was the worst option (does the GitHub UI even offer that option?). In general you perform a merge, for external contributions i prefer to always enforce a merge, even if like in this case a fast-forward merge would have been possible.

Also, it is kind of bad practice to create a PR from the main branch, in general you make a feature branch and create a PR from that one.

37

Plugins development / Re: GitBlocks to keep most of it working under Windows 10

« Last post by stahta01 on September 15, 2023, 09:28:09 pm »

Hi Tim,

I tested the plugin in Linux wx3.0, it works fine. I've created pull request https://github.com/stahta01/GitBlocks/pull/1 with project file. Could you please check?

Thanks,
Christo

This is the first time for me to process an PR; I think I did it right.

Tim S

38

Plugins development / Re: GitBlocks to keep most of it working under Windows 10

« Last post by christo on September 15, 2023, 06:04:23 pm »

Hi Tim,

I tested the plugin in Linux wx3.0, it works fine. I've created pull request https://github.com/stahta01/GitBlocks/pull/1 with project file. Could you please check?

Thanks,
Christo

39

General (but related to Code::Blocks) / Re: Using the screenshots in books

« Last post by MichaelAgarkov on September 15, 2023, 04:48:41 pm »

Apologies, and after searching, I think the answer is probably no, it was discussed here. Did not expect this rabbit hole to go deep.

40

Help / Re: Building project on command line with dependencies

« Last post by rgleim on September 15, 2023, 04:42:53 pm »

Looks like what I'm gathering is that you can't build a single project on the command line and have it figure out the dependent projects, and then build those.  Workspace builds work because it has knowledge of all other projects. Command line looks like you need to specify each individual project, in the order you want, to create the final executable.

I found the attached on the code::blocks wiki, but after setting up the external dependencies in the project, it's still not working on the command line.

Building the workspace works, but that doesn't work on the build machine because we don't save/have a workspace in the build system.

I did build the workspace. See bold from my previous posts.