Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Compiler plugin

<< < (2/3) > >>

comsytec:
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.

Jenna:
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.

comsytec:
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.

MortenMacFly:

--- Quote from: comsytec on December 27, 2012, 09:51:41 pm ---I see only this advance - dont need to create 2 targets anytarget_build and anytarget_release just anytarget and set global build configs.

--- End quote ---
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...


--- Quote from: comsytec on December 27, 2012, 09:51:41 pm ---When macro replacements are set then pass this via event sink to plugin thus give chance to handle not existing macros.

--- End quote ---
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.

comsytec:
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"}
--- End quote ---

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"}
--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page