Author Topic: Compiler plugin  (Read 7335 times)

Offline comsytec

  • Multiple posting newcomer
  • *
  • Posts: 58
    • www.comsytec.com
Compiler plugin
« on: December 27, 2012, 12:14:08 am »
We have created improved compiler plugin with new feature - BUILD CONFIGURATION -
Splits global options into multiple groups. Possible configs are - RELEASE - and - DEBUG -
Options editable via global configuration Settings > Compiler and debugger ...
Is it useful for someone ?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Compiler plugin
« Reply #1 on: December 27, 2012, 02:02:13 am »
I'm not sure how you implement this.
From my point of view, it is redundant, because I think the "build target" already have some kind of "release" or "debug" options.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline comsytec

  • Multiple posting newcomer
  • *
  • Posts: 58
    • www.comsytec.com
Re: Compiler plugin
« Reply #2 on: December 27, 2012, 08:48:07 am »
We you this feature when building workspace with virtual targets. The -g or -O2 are then set in build configuration options not in project options. This is useful when build virtual target over workspace with many projects.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: Compiler plugin
« Reply #3 on: December 27, 2012, 11:25:38 am »
We you this feature when building workspace with virtual targets. The -g or -O2 are then set in build configuration options not in project options. This is useful when build virtual target over workspace with many projects.
Can you be more precise? If you look at the C::B workspace its the same there w/o any extension: We have grouped targets using virtual targets there, too.

If you want to have a "release" and "debug" target across a WS what you need to do is:
- in each project create a "release" and "debug" target and setup its parameters
- in each project create a virtual target "release_build" where you select only the "release" target as member
- in each project create a virtual target "debug_build" where you select only the "debug" target as member
- add all projects to a WS
Select either "release_build" to only compile the "release" targets only or "debug_build" for the "debug" targets accordingly.

Note that you could also have another virtual target in each project named "All" which consists of both: The "release" and "debug" target. Selecting this will compile all targets in all projects for you then.

So I still fail to see whats new...?!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Compiler plugin
« Reply #4 on: December 27, 2012, 11:41:43 am »
Options editable via global configuration Settings > Compiler and debugger ...

This menu-point does not exist in actual release any more and what's more: after the release the compiler plugin has changed a lot (merge in of xml-compiler branch).
What is the version, your changes are based on ?

By the way if you want to have debug and release settings on global compiler level, it would be possible to create a debug and release compiler and use it on project level, so you do not need to do the settings for each project/target.

Offline comsytec

  • Multiple posting newcomer
  • *
  • Posts: 58
    • www.comsytec.com
Re: Compiler plugin
« Reply #5 on: December 27, 2012, 11:49:51 am »
So then you can imagine when you use msvcrtd and have many projects in a workspace (intentionally DONT WANT to convert these projects to targets, these projects containing many targets itself) and want just switch this to msvcrt. We just want make this switching as easy as possible. Till now we use method described above but with project grow this kind of management seems still harder.
We just ask if anyone is interested we can share it.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Compiler plugin
« Reply #6 on: December 27, 2012, 12:00:11 pm »
If you have a good, working concept for your target/project/workspace layout (probably using [user] templates to create the projects) it should not be much work to add a new project, if needed
If you have to switch a large workspace to a new layout, it might be correct, but this is nothing, that has to be done very often I think.

Offline comsytec

  • Multiple posting newcomer
  • *
  • Posts: 58
    • www.comsytec.com
Re: Compiler plugin
« Reply #7 on: December 27, 2012, 09:51:41 pm »
Our improvement was derived from compiler plugin version 0.99. We plan to move global options from default.conf file to be more close workspace related.
I see only this advance - dont need to create 2 targets anytarget_build and anytarget_release just anytarget and set global build configs. This can be also dynamically managed not only strict to debug / release ones.
Question to macros: would be possible to affect macro expansion through plugin ? When macro replacements are set then pass this via event sink to plugin thus give chance to handle not existing macros.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: Compiler plugin
« Reply #8 on: December 28, 2012, 01:03:20 pm »
I see only this advance - dont need to create 2 targets anytarget_build and anytarget_release just anytarget and set global build configs.
You can do this with macros now already...?! Maybe instead of misunderstanding you could post a simple patch that demonstrates what you've modified... I think I just don-'t get it...

When macro replacements are set then pass this via event sink to plugin thus give chance to handle not existing macros.
We could do so, but we don't always know if a macro has actually been replaced or not due to recursion.
However, are you aware that you can have per-target macros / variables that you could make use of for such purposes? Also, using scripting you can do even way more powerful macro replacements in the pre- or post-build steps.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline comsytec

  • Multiple posting newcomer
  • *
  • Posts: 58
    • www.comsytec.com
Re: Compiler plugin
« Reply #9 on: December 28, 2012, 02:01:08 pm »
The macro was the first idea to achieve build configuration but I gave up after two days of examining because the expansion fails in some situation. Only some example for post build step:
Quote
$if($(BUILD_CFG)==release){cmd /C "$(#pfx)\sign.bat $TARGET_OUTPUT_FILE"}

but this does not want to expand noway. The BUILD_CFG is custom variable with value release

Quote
$if($BUILD_CFG==release){cmd /C "$(#pfx)\sign.bat $TARGET_OUTPUT_FILE"}

is better but still not work. The great thing would be to have some option to see macro expansion in log for debugging.

Event sink handler for macro raised from BUILD_CFG custom var which is build config name but I could not set it in compiler plugin as e.g. $BUILD_CFG while it does not expand correctly in allow places. Example: object file name directory. But event sink handler in macro manager would be right place for it.

Improved compiler source code http://www.comsytec.com/public/advgcc.zip
« Last Edit: December 28, 2012, 02:03:47 pm by comsytec »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: Compiler plugin
« Reply #10 on: December 29, 2012, 11:07:13 am »
Quote
$if($(BUILD_CFG)==release){cmd /C "$(#pfx)\sign.bat $TARGET_OUTPUT_FILE"}
but this does not want to expand noway. The BUILD_CFG is custom variable with value release
Well if that is true its a bug and we should fix it. What makes me wonder is if you shouldn't use something like:
$if("$(BUILD_CFG)"=="release") ...
Because what you have shown here to my understanding shouldn't be a valid scripting command anyways. ???
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline comsytec

  • Multiple posting newcomer
  • *
  • Posts: 58
    • www.comsytec.com
Re: Compiler plugin
« Reply #11 on: December 29, 2012, 01:42:15 pm »
So for

Code: [Select]
$if("$(BUILD_CFG)"=="release"){cmd /C "$(#pfx)\sign.bat $TARGET_OUTPUT_FILE"}

in post build step the result is

Code: [Select]
("release"=="release"){cmd /C "c:\Work\IDEalCodeStudio\pfx\sign.bat ..\..\bin\release\epsdebugger.tdm.dll"}
Execution of '("release"=="release"){cmd /C "c:\Work\IDEalCodeStudio\pfx\sign.bat ..\..\bin\release\epsdebugger.tdm.dll"}' in 'C:\Work\IDEalCodeStudio\Plugins\TargetDeviceManager' failed.
Nothing to be done.

I havent seen that the regex m_RE_If or m_RE_IfSp in macrosmanager.cpp accepts double quotes