problem Custom command

[rob]

I made the strange experience that Custom commands only work, when defined at the Project-Setting. When trying to add such custom comands to an inidividal target (which of course id defined for adding its settings to the projectsettings), they don't get executed.
To be honest, I think I do something wrong, otherwise I would have posted it to the sourceforge Bugreports.

[mandrav]

I guess you 're talking about pre/post build steps. These are executed if your target's output is not up-to-date.

Example:
You have a target (with custom post-build step) producing a .dll. When this target compiles and links the dll, the post-build step is ran. Until you make any changes requiring the re-linking of the dll, the defined post-build step will not run again.
It behaves like its name suggests: "post-build step". If there is no "build" (the dll is up-to-date) there can be no post-build step.

I don't know if this is the expected behaviour, though, at least for guys coming from Visual Studio world. It's just what makes more sense. Still, I can see the need for commands being executed no matter if the build is up-to-date or not...

Opinions anyone?

Yiannis.

[EricBurnett]

I personally would like them to execute every time. It is more what I expect, and I think it would be more useful.

[rickg22]

I got an idea. Why not follow the Dev-C++ model? This is, generating the targets and re-generating them everytime the compile (ctrl-f9) is done?

[mandrav]

I got an idea. Why not follow the Dev-C++ model? This is, generating the targets and re-generating them everytime the compile (ctrl-f9) is done?

If we had to like every function of devcpp, we better use it then and stop working on Code::Blocks  
For my needs, for example, I want the commands executed only when linking (a.k.a refreshing the exe/dll/etc).
But, as mentioned, I understand the need for commands that execute no matter what.

I can think of two solutions:

• Put a checkbox at the commands page, indicating if we want them to be executed every time or not
• Add two more commands boxes and have different commands for every-time execution and different for linking-time-only execution[/list:u]
  
  How does it sound? Which do you prefer? Any more ideas?
  
  Yiannis.

[Profic]

I have no need for this, but have some ideas
It seems that to make all people happier we need four separate command boxes. Two for build command and two for compile command.
And in addition it seems there is need for checkbox for selection order of them (Then build target is updated that execute first - post-build or post-compile?)
That's my two cents

[tiwag]

...solutions:

• Put a checkbox at the commands page, indicating if we want them to be executed every time or not[/list:u]
  ...

i think the majority of needs can be managed with that,
if one needs aditional pre-/post- compile-/link- stage commands,
it can easily be done by adding dummy targets pre-/post- added
to  the very target and checking the checkbox'es accordingly.

i hope you can understand what i mean

Targets:
...
XYZ_pre_compile_always_done_commands  
XYZ_pre_compile_commands  
XYZ_target                  <<< here is the real compiled code xyz.cpp,...
XYZ post_link_commands
XYZ post_link_always_done_commands
...

--tiwag

[mandrav]

I thought it over and I just made it run the steps no matter what.
It seems that most people like it this way.

On to more important matters now

Yiannis.

[Urxae]

I thought it over and I just made it run the steps no matter what.
It seems that most people like it this way.

Please don't do that, because if these commands return error codes, the build fails.
For example: when I compile .dlls, I usually have it generate the .a files as well, and in post-build commands move these to the lib/ subdirectory. When I build the entire project and the dll doesn't need to be relinked, that move command will halt the build for no good reason.

[mandrav]

...that move command will halt the build for no good reason.

Do you care to elaborate?
Why would it halt the build? What kind of error might be raised?

Yiannis.

[Urxae]

I have a post-build command like this:

Code

mv *.a lib/

Now, if there are no .a files in the current directory (because they've all been moved to the lib/ directory already) this will return a non-zero exit code. This will prevent any later targets from being compiled.

For example, I just created a new project in an empty directory. I added an extra target after the default one (with a different .exe name ofcourse), and one .cpp file per target containing the most trivial program possible:

Code

int main() {}

I then added the post-build command above ('move *.a lib/') to the default target (and created a directory lib just to be complete). Now when I 'build all', I get:

Code

Project   : Untitled1
Compiler  : GNU GCC Compiler (called directly)
Directory : D:\C++\Projects\Example\
--------------------------------------------------------------------------------
Linking executable: Untitled1.exe
Running post-build step: default
mv: cannot stat `*.a': No such file or directory
Process terminated with status 1 (0 minutes, 1 seconds)
0 errors, 0 warnings

So the second target won't be built. Now imagine the first target was a .dll, so the post-build command would actually make sense. That post-build command would then be successful only the first time after the .dll was last built. If the command was run even when the .dll didn't need to be rebuilt, Code::Blocks would return above error each and every time when 'rebuilding all' until the .dll was for whatever reason rebuilt. Not good.

[mandrav]

OK, so my point was valid when I was saying that not everyone wants the commands to always run
I 'll add configuration for it.

Yiannis.