Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » C / C++ IDE (CDT) » custom toolchain: Decide to archive instead of link based on the folder
custom toolchain: Decide to archive instead of link based on the folder [message #1007440] Tue, 05 February 2013 21:10 Go to next message
jan baeyens is currently offline jan baeyens
Messages: 11
Registered: March 2012
Junior Member
Hi
I have developed a CDT plugin to build and compile arduino projects.
I did so by having 2 projects. 1 for the arduino code (consider this a library) and 1 for the real arduino project.
I'm currently redisigning the plugin and I would like to change the 2 project design to 1 project design because I need to share "defines" between the 2. As each project can have a different value for the "define" a shared project is no longer a option.
Therefore I would like to have the arduino code in a folder in my project.
But how do I tell the toolchain it needs to "archive" the arduino objects and "link" the rest.
I have tried by having another toolchain for the arduino folder that compiles to .O insted of .o files and then the archiver processes .O files and the linker links .o files. I found that the Arduino folder wasn't build (I may have had a wrong setting )

I have tried using a option to switch compilers in the same way of thinking as the previous. However I found the option to be global for the project (again I may have had a wrong setting)

Any help on wether this is possible or how to get this to work would be really appreciated.
Best regards
Jantje
Re: custom toolchain: Decide to archive instead of link based on the folder [message #1007944 is a reply to message #1007440] Fri, 08 February 2013 11:14 Go to previous messageGo to next message
Tamas Csabina is currently offline Tamas Csabina
Messages: 25
Registered: November 2012
Junior Member
Hi,

I have done something similar. Not completely what you ask for, but might to the trick for you as well.

There are 2 tools in my toolchain: a kind of pre-processor, a compiler, and a linker.
The pre-processor only used on certain files, not on all of them.
In Project->Properties->C/C++ Build->Tool Chain Editor I only assigned the compiler and the linker to the project, not the pre-processor.
And for the files I want the pre-process to `process` the file, I select the file in the Project Explorer, right-click->Properties, and override the project`s setting for Tool Chain, and define the pre-processor as an extra tool for these files.

Re: custom toolchain: Decide to archive instead of link based on the folder [message #1008195 is a reply to message #1007944] Mon, 11 February 2013 11:41 Go to previous messageGo to next message
jan baeyens is currently offline jan baeyens
Messages: 11
Registered: March 2012
Junior Member
Tamas
Thanks for the response. I have continued my quest to get this to work and I understand better why I have failed until now. I'm sure there is a bug in the toolchain processing in regards to the processing of the field "buildvariable" when using multiple "outputtypes".
I need to do some more investigations before I can create a bug report.
Best regards
Jantje
Re: custom toolchain: Decide to archive instead of link based on the folder [message #1010565 is a reply to message #1008195] Sun, 17 February 2013 18:13 Go to previous message
jan baeyens is currently offline jan baeyens
Messages: 11
Registered: March 2012
Junior Member
I found 3 bugs and a way to fix them.
I posted the mail (see below) containing the bugs and the fixes to the cdt developers mailing list.
As my problem is fixed I will only follow up on the cdt mailing list to see wether this will be fixed in cdt.

Best regards
Jantje

Hi
I succeeded to make a toolchain that allows me to have a library and my project code in the same project.
The difficulty in doing so is that the datamodel supported in plugin.xml is not supported by the default class GnuMakefileGenerator.

Technically I need to "split" the code to send part of it to the archiver and part of it to the linker.
As the plugin.xml allows for multiple outputtypes for 1 tool and each output type has its own "buildVariable" I thought it would be possible to get this to work with the standard toolchain.

The solution I came up with is as follows:
Using 2 "primary output" "outputtypes" with different "build variable" (AR_OBJ and LINK_OBJ) values and different (complementary) "name providers".
AR_OBJ is used as input for the archiver and LINK_OBJ is used as input by the linker.
Using 2 complementary "name provider"s I filter the files that need to go to the linker or the archiver. I can do this easily because the files to archive are in a subfolder.
Both of the outputtypes must be primary output (at least as far as I understood)
So there are 3 key attributes. I found a bug in all 3 of them in GnuMakefileGenerator.

I copied the code of GnuMakefileGenerator to create my own MakefileGenerator to make it work and I found that only some minor changes are needed to get it to work. Moreover the changes look more like bug fixes than enhancments.

Problem 1 : When using more than 1 output type with the flag "Primary output" only the first one is found. All others are ignored. I consider this a bug as the data model allows to have multiple "primary output"s. If there can only be one it should be defined in the "tool" object and not in the "output type"

Problem 2: Buildvariable is always the buildvariable defined in the first "outputtype" taged with "primary output type true" and if none tagged the first output type is used. I consider this to be a bug as the data model allows to specify a build variable for each outputtype but the code ignores this.

Problem 3: Name provider can not return null. As such it is impossible to completely ignore a input file. All cases -except one- cater for null. The fact that the default generated code returns null does not prove the code should support null but ....

Fixing problem 1 and 2 may introduce downwards incompatibility. Fixing problem 3 will not introduce downwards incompatibility. I think it would be a good idea to fix this in the CDT code.

How I fixed it.
Problem 1:
on line 3113 it states :
boolean primaryOutput = (type == tool.getPrimaryOutputType());
Replacing with
boolean primaryOutput = type.getPrimaryOutput();
Fixes the bug.

Problem 3: (I do 3 first as the solution of 2 is easier to explain when 3 is done)
on line 3256/7 it states:
IPath[] outPaths = nameProvider.getOutputNames(tool, inPaths);
for (int j=0; j<outPaths.length; j++) {
...
}
This fails if nameProvider.getOutputNames(tool, inPaths); returns a null.
as outPaths is no longer used after the for loop the code below fixes the problem
IPath[] outPaths = nameProvider.getOutputNames(tool, inPaths);
if (outPaths!=null){
for (int j=0; j<outPaths.length; j++) {
...
}
}

Problem 2: (this one needs changes at several locations)
The bug is at line 2168
IOutputType outType = tool.getPrimaryOutputType();
because later (2148) it states
buildVariable = outType.getBuildVariable();
This way the build variable is always the build variable of the PrimaryOutputType or the first outputtype if none is provided.
To fix this I removed the line and changed outType to a field (I refactored/rename to usedOutType)
The code changed in Probem 3 knows the outputType so I changed that to
IPath[] outPaths = nameProvider.getOutputNames(tool, inPaths);
if (outPaths!=null){
usedOutType=type;
for (int j=0; j<outPaths.length; j++) {
...
}
}
To make sure the code doesn't use old "output type" values I changed line 2108 from
addRuleForSource(relativePath, ruleBuffer, resource, sourceLocation, rcInfo, generatedSource, generatedDepFiles, generatedOutputs);
to
usedOutType = null;
addRuleForSource(relativePath, ruleBuffer, resource, sourceLocation, rcInfo, generatedSource, generatedDepFiles, generatedOutputs);

This is all that is needed to fix it.
My question now is: Do I need to bother to create defects? And if so do I create 1 for the 3 changes or 3 defects?

Best regards
Jantje

[Updated on: Sun, 17 February 2013 18:14]

Report message to a moderator

Previous Topic:Can't create C++ project
Next Topic:EOF during runtime in C console
Goto Forum:
  


Current Time: Thu Oct 30 23:58:10 GMT 2014

Powered by FUDForum. Page generated in 0.03230 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software