Compiler/Linker variables

[killerbot]

Hello,

I am trying to add the Texas Instruments Code Composer Studio compiler to CB.
But I am running into several problems :

1) do the following variables exist ? and if not can they be created ?
  - the objects output directory, this can be specified in the Target configuration (for example ./TIobjs), but I need it as a variable in the advanced compiler/linker settings
TI compiler needs an option like this : -fr"./TIDebugObjs" just telling it where to put the obj's, and the output file needs not to be specified, here's a full compiler command :

"C:\CCStudio\C6000\cgtools\bin\cl6x" -q -o2 -fr"../tiRelease" -i"../inc" -i"../src" -i"../../General/inc" -ml3 -mv6400 [email protected]"../Release.lkf" "Codec.cpp"

--> so no -c option, no -o option
 - maybe also the output directory for the static library/exe/... (could reuse the directory for the obj's for this)

2) self made variables show up weird or incorrect ?
As a workaround I tried to create an custom variable for the compiler :
  objects_output_dir=".TIDebugobjs"
and changed the compiler line macro to :
  $compiler $options $includes $file -fr$(objects_output_dir)
but i get replaced wrong :
  a)$objects_output_dir  --> conflict with $objects, this latter goes first (so no longest substitution)
  b)$(objects_output_dir) --> no more conflict but during compile we get the following :
cl6x.exe   -g  -q -mv6400   -I"..\General\inc" -I"inc"  -I"C:\CCStudio\C6000\cgtools\include" src\CodecDebug.cpp -fr$(objects_output_dir)

No substitution ? It seems like it, though maybe it was substituted.
Note also the filename of the cpp, it contains a part of the relative path, sources are in a subdir "src" of the project directory. But maybe this latter thing can be dealed with, you just get in the obj's directopry also that src subdir and so on ..., just need to specify it then correctly to the linker.

3) is the target name available as variable ?


kind regards,
Lieven

[thomas]

With RC2, you can use the following bultins:
${PROJECT_FILENAME}
${PROJECT_NAME}
${PROJECT_DIR}
${ACTIVE_EDITOR_FILENAME}
${ALL_PROJECT_FILES}
${MAKEFILE}
${OUTPUT_FILE}
${OUTPUT_DIR}
You will want to use ${OUTPUT_DIR}. If you have the targets foo and bar, you would use ${FOO_OUTPUT_DIR} and ${BAR_OUTPUT_DIR}, respectively. The current per-target output file/dir are not supported at the present time.

With HEAD, you can use:
${PROJECT_FILENAME} ${PROJECT_FILE} ${PROJECTFILE}
${PROJECT_NAME}
${PROJECT_DIR} ${PROJECTDIR} ${PROJECT_DIRECTORY}
${CODEBLOCKS} ${APP_PATH}  ${APPPATH}
${DATA_PATH} ${DATAPATH}
${PLUGINS}
${ACTIVE_EDITOR_FILENAME}
${ALL_PROJECT_FILES}
${MAKEFILE}
${OUTPUT_FILE}
${OUTPUT_DIR}

I don't know if you can omit the -o flag without recompiling the compiler plugin (but I doubt it).

a)$objects_output_dir --> conflict with $objects, this latter goes first (so no longest substitution)
 b)$(objects_output_dir) --> no more conflict but during compile we get the following :
cl6x.exe -g -q -mv6400 -I"..\General\inc" -I"inc" -I"C:\CCStudio\C6000\cgtools\include" src\CodecDebug.cpp -fr$(objects_output_dir)

Hmm this looks like a bug, will see if I can reproduce it and find a cause.

3) is the target name available as variable ?

Not at the present time.

[thomas]

a)$objects_output_dir --> conflict with $objects, this latter goes first (so no longest substitution)
 b)$(objects_output_dir) --> no more conflict but during compile we get the following :
cl6x.exe -g -q -mv6400 -I"..\General\inc" -I"inc" -I"C:\CCStudio\C6000\cgtools\include" src\CodecDebug.cpp -fr$(objects_output_dir)

Hmm this looks like a bug, will see if I can reproduce it and find a cause.

Could not reproduce that.

3) is the target name available as variable ?

Not at the present time.

Trying to implement that. It is not as trivial as it looks, however.

Or, do you only need the target's name inside the compiler?

[killerbot]

When target name could be on interest.

Suppose you have a project.

Several targets :

1) Target 1 : Debug : using GNU CB compiler
2) Target 2 : release : using GNU CB compiler
3) Target 3 : using Digital Mars Compiler
4) Target 4 : using M$ compiler debug
5) Target 5 : using M$ compiler release
6) Target 6 : using TI compiler debug
7) Target 7 : using TI compiler release
Target 8 : using WindRiver compiler debug
9) Target 9 : using WindRiver compiler release

and so on.
This is not fantasy, reality at my job.

As mentioned for the TI compiler I need to specify stuff as -fr"../tiDebug" and [email protected]"../Debug.lkf"
a) -fr"../tiDebug", here I could use the ${OUTPUT_DIR}
b) [email protected]"../Debug.lkf", the ti compiler appends stuff to a response file, that later on is used during the linking step, ti compiler is very crappy on paths, so it's best to leave it where ti preferres it. So here it would be nice to create as filename for that response file [email protected]"../$(target_name).lkf"

And it is best that this is a compiler setting (may be in the advanced where we customize specify it), but preferably not in the project itself.

I guess for other stuff the target name might also be interesting, but on the other hand maybe there are workarounds to accomplish the same thing without this new variable ...


Cheers,
Lieven

[thomas]

When target name could be on interest.
[...]
This is not fantasy, reality at my job.

Not what I asked. I understand that you write a compiler plugin for the TI compiler, and this compiler needs the build target's name (for what reason does not matter). Is that the case?

The issue of providing the current target's name as a general builtin compiler variable is an entirely different one and a lot more complicated. But if it is just the above that you need, it is really easy.

[tiwag]

i also have similar needs as killerbot and tried to define a custom variable named <target> for each target with a different string, in the hope, that when i use the custom variable $(target) i'd get the appropriate string related to the actual selected target,
and use it in the output file, object dir and deps-dir settings.

you see the idea best when looking into the project file...

Code: [Select]

<?xml version="1.0"?>
<!DOCTYPE CodeBlocks_project_file>
<CodeBlocks_project_file>
<FileVersion major="1" minor="1"/>
<Project>
<Option title="Target test"/>
<Option makefile="Makefile"/>
<Option makefile_is_custom="0"/>
<Option pch_mode="2"/>
<Option active_target="0"/>
<Option compiler="0"/>
<Build>
<Target title="target1">
<Option output="wxapp_$(target).exe"/>
<Option working_dir="."/>
<Option object_output=".objs_$(target)"/>
<Option deps_output=".deps_$(target)"/>
<Option type="0"/>
<Option compiler="0"/>
<Option projectResourceIncludeDirsRelation="0"/>
<Environment>
<Variable name="target" value="T1"/>
</Environment>
</Target>
<Target title="target2">
<Option output="wxapp_$(target).exe"/>
<Option working_dir="."/>
<Option object_output=".objs_$(target)"/>
<Option deps_output=".deps_$(target)"/>
<Option type="0"/>
<Option compiler="0"/>
<Option projectResourceIncludeDirsRelation="0"/>
<Environment>
<Variable name="target" value="T2"/>
</Environment>
</Target>
<Target title="target3">
<Option output="wxapp_$(target).exe"/>
<Option working_dir="."/>
<Option object_output=".objs_$(target)"/>
<Option deps_output=".deps_$(target)"/>
<Option type="0"/>
<Option compiler="0"/>
<Option projectResourceIncludeDirsRelation="0"/>
<Environment>
<Variable name="target" value="T3"/>
</Environment>
</Target>
<Environment>
<Variable name="WX_DIR" value="d:\wx261"/>
<Variable name="WX_CFG" value=""/>
</Environment>
</Build>
<Compiler>
<Add option="-pipe"/>
<Add option="-mthreads"/>
<Add option="-Winvalid-pch"/>
<Add option="-include &quot;wx_pch.h&quot;"/>
<Add option="-D__GNUWIN32__"/>
<Add option="-D__WXMSW__"/>
<Add option="-DWXUSINGDLL"/>
<Add option="-DUSE_PCH"/>
<Add directory="$(WX_DIR)\include"/>
<Add directory="$(WX_DIR)\lib\gcc_dll$(WX_CFG)\msw"/>
<Add directory="$(WX_DIR)\contrib\include"/>
</Compiler>
<ResourceCompiler>
<Add directory="$(WX_DIR)\include"/>
</ResourceCompiler>
<Linker>
<Add library="wxmsw26"/>
<Add directory="$(WX_DIR)\lib\gcc_dll$(WX_CFG)"/>
</Linker>
<Unit filename="main.cpp">
<Option compilerVar="CPP"/>
<Option target="target1"/>
<Option target="target2"/>
<Option target="target3"/>
</Unit>
<Unit filename="main.h">
<Option compilerVar=""/>
<Option compile="0"/>
<Option link="0"/>
<Option target="target1"/>
<Option target="target2"/>
<Option target="target3"/>
</Unit>
<Unit filename="wx_pch.h">
<Option compilerVar="CPP"/>
<Option link="0"/>
<Option weight="0"/>
<Option target="target1"/>
<Option target="target2"/>
<Option target="target3"/>
</Unit>
</Project>
</CodeBlocks_project_file>

this approach almost works, when the custom variable <target> isn't defined at project level but only at target levels,
but the target-dependency of this custom variable is somehow scrambled.

* when i build target1, $(target) is set to "T3",

Code: [Select]

Project   : Target test
Compiler  : GNU GCC Compiler (called directly)
Directory : D:\cpp\_projects\CodeBlocks\TESTS\target_test\
--------------------------------------------------------------------------------
Switching to target: target1
mingw32-g++.exe   -pipe -mthreads -Winvalid-pch -include "wx_pch.h" -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DUSE_PCH    -Id:\wx261\include -Id:\wx261\lib\gcc_dll\msw -Id:\wx261\contrib\include  -c main.cpp -o .objs_T3\main.o
mingw32-g++.exe   -Ld:\wx261\lib\gcc_dll  -o wxapp_T3.exe .objs_T3\main.o        -lwxmsw26  -mwindows
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings

* when i build target2, $(target) is set to "T1",

Code: [Select]

Project   : Target test
Compiler  : GNU GCC Compiler (called directly)
Directory : D:\cpp\_projects\CodeBlocks\TESTS\target_test\
--------------------------------------------------------------------------------
Switching to target: target2
mingw32-g++.exe   -pipe -mthreads -Winvalid-pch -include "wx_pch.h" -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DUSE_PCH    -Id:\wx261\include -Id:\wx261\lib\gcc_dll\msw -Id:\wx261\contrib\include  -c main.cpp -o .objs_T1\main.o
mingw32-g++.exe   -Ld:\wx261\lib\gcc_dll  -o wxapp_T1.exe .objs_T1\main.o        -lwxmsw26  -mwindows
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings

and finally

* when i build target3, $(target) is set to "T2"

Code: [Select]

Project   : Target test
Compiler  : GNU GCC Compiler (called directly)
Directory : D:\cpp\_projects\CodeBlocks\TESTS\target_test\
--------------------------------------------------------------------------------
Switching to target: target3
mingw32-g++.exe   -pipe -mthreads -Winvalid-pch -include "wx_pch.h" -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DUSE_PCH    -Id:\wx261\include -Id:\wx261\lib\gcc_dll\msw -Id:\wx261\contrib\include  -c main.cpp -o .objs_T2\main.o
mingw32-g++.exe   -Ld:\wx261\lib\gcc_dll  -o wxapp_T2.exe .objs_T2\main.o        -lwxmsw26  -mwindows
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
when i select  build target All, $(target) is set to "" (blank)

 


attached is the project, if someone wants to test with it.

[attachment deleted by admin]

[killerbot]

Thomas,


You lost me, don't understand the difference betwen the 2 things you are saying.  :oops:

Every target you build has a name, that name is known in the cbp file, there it has been specified.

Now when the build starts, there are variables that can be used by the compile, the linker, etc ...
Most of them are listed on the "Compiler Settings->Other tab -> Advanced Options -> Commands tab", if possible it would be of great help to have for example $(target)
Example from a cbp :
         <Target title="default">
         <Target title="dmc">

So for example I could specify for compiler x :  not using the target variable

$compiler $options $includes -c $file -o $object

for compiler y :
$compiler $options $includes -c $file -fr"$(target)blablablabla"

for compiler z:
$compiler $options $includes -c $file -o $object -myoption=$(target)

where I get's replaced for example by default, or by dmc, ...


I hope this falls under the "really easy" part you are mentioning.

kind regards,
Lieven

[thomas]

What I meant with "really easy" was accessing that kind of information from cbCompilerPlugin or from Compiler. Providing it as a compiler variable is rather complicated, because you don't have that information at this time.

But don't worry, there's a workaround. The build target will soon be supported as a plain normal compiler variable, too. cbProject gets a new function to query the currently compiling target, and this is read by the macro manager to provide this information in a $(VARIABLE).
The information in cbProject is updated each time the compiler switches build targets in its run queue.
So much for the theory... I have it implemented so far, but updating on target switch alone seems not enough (it works after the 2nd build, but not before). I tried for a while, but ran out of ideas at some point.

Since tiwag has personal interest in the matter, too, I sent him the patch for review. He will very likely find the piece that is missing, and then we're set.

[killerbot]

wonderfull news.

Time I learn to build CB from cvs, so I can test it once it is checked in ...

[tiwag]

...Since tiwag has personal interest in the matter, too, I sent him the patch for review. He will very likely find the piece that is missing, and then we're set.

i'll try to find time to look at it - but please don't be too optimistic - at the moment i've soo much troubles at work that i don't have any free time. It's a kind of short-time vacation when i look for 15 minutes into this forum and read a few articles - so please don't be disappointed if i can't respond with some solution very fast at the moment.