Code::Blocks Forums

User forums => Help => Topic started by: rob on May 17, 2005, 07:12:39 am

Title: problem Custom command
Post by: rob on May 17, 2005, 07:12:39 am
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.
Title: problem Custom command
Post by: mandrav on May 17, 2005, 08:38:43 am
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.
Title: problem Custom command
Post by: EricBurnett on May 18, 2005, 12:29:54 am
I personally would like them to execute every time. It is more what I expect, and I think it would be more useful.
Title: problem Custom command
Post by: rickg22 on May 18, 2005, 02:35:35 am
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?
Title: problem Custom command
Post by: mandrav on May 18, 2005, 08:41:37 am
Quote from: 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?

If we had to like every function of devcpp, we better use it then and stop working on Code::Blocks   :D
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:
Title: problem Custom command
Post by: Profic on May 18, 2005, 10:41:51 am
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 :)
Title: problem Custom command
Post by: tiwag on May 18, 2005, 01:55:01 pm
Quote from: mandrav
...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
Title: problem Custom command
Post by: mandrav on May 18, 2005, 02:09:28 pm
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.
Title: problem Custom command
Post by: Urxae on May 18, 2005, 05:24:13 pm
Quote
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.
Title: problem Custom command
Post by: mandrav on May 18, 2005, 06:58:31 pm
Quote
...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.
Title: problem Custom command
Post by: Urxae on May 18, 2005, 08:15:13 pm
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.
Title: problem Custom command
Post by: mandrav on May 18, 2005, 09:34:56 pm
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.