Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Re : Re: Using ScannerInfoProvider and "Includes" project element

This sounds a lot like what I did.

 

This is how our build system works:

 

A set of source files is built with a build script. This is a proprietary build script format with extention bld. These build scripts can have many different types of inputs. They handle makind message files, generating code, and also just building libraries and executables. So the only real command that I execute is the build script runner. This leads me to the problem where I might have many files in my project that need the same command line, which is why I had to create dummy tools so that I could filter the inputs.

 

Anyways, with all that being said, doing it this way does not seem to allow me to use the LanuageSettingProvider

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of guy.bonneau@xxxxxxxxxxxx
Sent: Thursday, September 19, 2013 9:42 AM
To: CDT General developers list.
Subject: [cdt-dev] Re : Re: Using ScannerInfoProvider and "Includes" project element

 

I have the same issue here but with a different context!

 

Basically I have a toolchain that needs to process the input resources in a multipass step  feeding the same inputs to the same tools with in between intermediary processing with others tools. Like you the only way I was able to make this happen was to create dummy tools that produces fake outputs.

 

In my case I was able to reformat the inputs and outputs I needed by implementing the CommandLineGenerator attribute of the tool with the interface IManagedCommandLineGenerator. As the build proceeds I receive all the command variable pattern ${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}. I know which tool is invoked and I then proceed to rename/reparse the outputs and/or inputs as the tools are invoked. I keep all the context of the invocation in many static maps and I know what going on as the tools are invoked. 

 

Note that you can redefine all the variables pattern to whatever you want thus rewriting the whole command line. Even invoking batch file or others applications that are not defined in the toolchain.

 

I admit that this is a very ugly hack and bypass fundamental aspect of the CDT architecture. I am looking forward to understand if there is a better way. But until I know better that saved my life.

 

Guy

 


Le 18/09/13, Joseph Henry <Joseph.Henry@xxxxxxx> a écrit :

This is not working for me, and I think it is because I cant seem to get a lanuageSEttingProvider attached to my toolchain (on the “preprocessor Include Paths, Macros, etc.” page I get a “Cannot Determine Toolchain Languages” message.

 

I think this is how I have my tools setup, but I could not realy find a way to setup my toolchain to produce the proper output. Maybe this is a good time to describe my problem, and the approach that I took that is now leading to this problem.

 

Our build system is quite unique. We have a distributed system, and we use “Sparse” projects. This means that we don’t actually invoke the compiler, we call a separate tool “sdsbuild” which reads build script(s) and then executes the proper commands to build the source files.

 

Basically what I want is this:

Lets say that we have this setup:
file a.c builds with script script1.bld
file b.c builds with script script1.bld
file c.c builds with script script2.bld
so, the build command should be something like: sdsbuild script1, script2

This could also be something like sdsbuild script1; sdsbuild script2

But I need to have just 1 invocation the build command for both a.c and b.c

 

 

The only way that I could find to make this happen was to create “dummy” tools that produce fake outputs that are then piped into another tool that filters out the inputs, and creates a mashed up command line.

 

If you have a suggestions, I would really appreciate it.

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev
Sent: Tuesday, September 17, 2013 4:05 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Using ScannerInfoProvider and "Includes" project element

 

I described it at http://wiki.eclipse.org/CDT/Developer/FAQ#How_do_I_contribute_Include.2FLibrary_paths_or_Macros_to_a_project_configuration_using_LanguageSettingsProvider_extension_point.3F.

 

To solve this particular problem that you stated - with supplying one set of entries for one specific file and another for all others - you could implement a provider along these lines:

 

public class YourProvider extends LanguageSettingsBaseProvider {

   public List<ICLanguageSettingEntry> getSettingEntries(ICConfigurationDescription cfgDescription, IResource rc, String languageId) {

      if (your_rc.equals(rc))

         return your_rc_entries;

      else

         return common_entries;

      

   }

}

 

Thanks,

Andrew

 

On Tue, Sep 17, 2013 at 12:41 PM, Joseph Henry <Joseph.Henry@xxxxxxx> wrote:

How does that work?

Could you give me an example of how to do this?

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev
Sent: Tuesday, September 17, 2013 11:53 AM


To: CDT General developers list.
Subject: Re: [cdt-dev] Using ScannerInfoProvider and "Includes" project element

 

Hi Joseph,

LanguageSettingsProviders are designed to support entries per resource basis. If you have 1 resource that is different you can set the common entries on project level and different set of entries for the specific resource.

 

Thanks,

Andrew

 

On Tue, Sep 17, 2013 at 10:56 AM, Joseph Henry <Joseph.Henry@xxxxxxx> wrote:

I have an interesting problem that maybe somebody on this list could help me with.

 

We have a custom tool chain, and to put it simply, we are required to provide a ScannerInfoProvider implementation so that we can properly return IScannerInfo on a per resource basis. We do this because 1 resource in a project can have a much different include path that another, so putting them all in the LanuageSettings was not acceptable.

 

With all this said, here is my problem:

 

Since we are not using the LanguageSettingProvider to give all the search include paths, the “Includes” project element does not show up any more. This is the UI element that you can expand and see the include folders, and further expand to see the files, etc.

 

Is there any way that I can:

 

1.)    Have this element use the search path that I return from my ScannerInfoProvider

2.)    Append the paths in the Language Settings also. (I still want to have this work so that users have a way to manually specify search paths.)

 

Any help with this would be great. As far as I can tell, the Java class that somewhat control the contents of the Includes element is org.eclipse.cdt.internal.ui.cview.IncludeRefContainer.

 

Thanks,

Joseph Henry.

 

 


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 

 


Back to the top