#1056 "Objects output dir" field is silently deleted

[Carra]

This bug was found on nightly build SVN 12253, but I have also confirmed it in another PC in a much older version: SVN 11628 from 2019.

These are the steps to reproduce it:

1) Create a new empty project
2) In project properties, set the project type to Commands only
3) In Objects output dir, type or choose any folder and press OK
4) Whenever you reenter project properties, the 'Objects output dir' field has been deleted

This also causes compiler errors, since that field is normally never empty (even for the current folder, there is always at least a dot).

[bluehazzard]

Can you give me a use case for this?
I assume you are thinking about only running the commands in Pre and Post build steps?

I tried your steps and can reproduce the problem, but i think this is wrong use of the type of build target.
I see there are 2 bugs here:
1) The objects output dir is not disabled in this step, you should not be able to enter something with a command only build target
2) If you run a command only target without any text in Pre and Post build steps the compiler command will be called:

x86_64-w64-mingw32-gcc.exe   -c C:\##########\wert\qwerqweqwerrrrw\main.c -o \main.o
Assembler messages:
Fatal error: can't create \main.o: Permission denied

The question is what should happen here?

[Carra]

Hi bluehazzard. Maybe then the only problem is that the field does not apply and should be disabled. I can't really answer that because I haven't been able to find any online help about how the command only target is supposed to work.

I was trying to see if using this configuration could help me use a custom build system that I need to compile a console game, since the process is not "c -> obj -> executable" as in PC programs.

[bluehazzard]

Can you give me an example how you implemented it, or how the commands would look like?

[Carra]

Yes, the process in general would be like this:

1. Call the compiler, which transforms C to assembly.
2. Call the assembler, which produces a binary file. This must be done separately from step 1.
3. Call converter programs for image and sound files that exist in the project.
4. Call the packing program. This program takes in an XML file to know which files to pack (which are all files produced in steps 2 and 3) and creates the final game rom.

In this case, only the final packed rom is actually executable. The binary alone is not.

[Teodor Petrov]

You can use either this http://wiki.codeblocks.org/index.php/Adding_support_for_non_C/C%2B%2B_files_to_the_build_system

Or post-build steps. This is how we setup embedded project for avr/arm/etc and it works sort of OK (there is no dependency tracking in the post build steps, but it is a start.
Another option is to use separate builds system like make/ninja/something else.

[Carra]

Thank you Teodor. This is an option I had also considered, in fact I was trying to use "commands only" so that the regular project-based compilation was avoided entirely. That way I could instead run a batch file that does the whole process.

Still, if I used something like this, would Code::Blocks still be able to track and show errors just like it does in a regular compilation? Or would running an external script prevent that?

Also, I still don't see clearly what the use case of "commands only" would be then. My guess was it should be used for cases like this. Maybe someone familiar with it can tell us about it, since it is not mentioned in the online help?

[Teodor Petrov]

Error tracking is based on exit codes and parsing the output with regular expressions.

[Teodor Petrov]

Please start a topic on the forum. There a lot fewer people following tickets, in the forum there are more people.

[bluehazzard]

@devs:
I can not fix this unless i understand how the CommandOnly target type is intended to work... I read the code, but i do not get any clue about it...

Is it intended to make operations on files?
This will not work, unless we introduce some special syntax in the pre/post build steps, or give the user the ability to give the command in a separate options field. It will work if the user uses squirrel scripting in the pre build commands (i think this is the best use case...)

Is it intended to call a compiler?
If yes, then why do all compiler options are disabled?
If no, why is in the DirectCommands::GetTargetCleanCommands the call to Compiler* compiler = target ? CompilerFactory::GetCompiler(target->GetCompilerID()) not gated. If the target CommandOnly is not intended to call a compiler why is the clean step then a compiler used, or why does it not return an empty command array?

Is it intended to call a Linker?
If yes, then why do all linker commands are disabled, but in the DirectCommands::GetTargetLinkCommands(ProjectBuildTarget* target, bool force) does return a none empty array for CommandOnly targets?

The same for the compiler. And this hits the problem for the user... The compiler is called for a command only target, but no options or files, or output files are defined/can be defined...

As far as i understand the CommandOnly target is broken as how it is implemented right now...

Attached are two patches, the first fixes the UI, the second fixes the building of the target... As soon as my questions are answered we can clean up some code...