Hi Andrew,
Thanks, yes, that makes sense.
I have now imported the whole AOSP source tree as a single project and CDT does an excellent job at getting compilation settings from the build output
J.
The only downside is that with this setup EGit does not recognise the files as being under version control (and the project is really massive: just refreshing
the resource tree takes a long time on a really fast machine…).
So I’ll stick with this setup and in background I’ll try to get the one with multiple projects working.
I’m now thinking to write a specific SettingsProvider (based on the GCC output parser) that feeds the same settings to each project that uses it.
This way when a build is triggered its output is parsed and each project would take the bits related to its own files.
Do you think this is a sensible approach?
Cheers
Fabrizio
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Andrew Gvozdev
Sent: Monday, August 19, 2013 3:03 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Settings parser on multiple projects
Hi Fabrizio,
Yes, it works as intended. I don't know if assumptions for a different project would be reliable. If the same file gets compiled from different projects compiler options could be different as well.
On Mon, Aug 19, 2013 at 6:57 AM, Iannetti, Fabrizio <fabrizio.iannetti@xxxxxxxxx> wrote:
Hi,
Is the settings parser supposed to add settings also to files belonging to other projects than the
one being built?
The AbstractLanguageSettingsOutputScanner class seems to search for files in the whole workspace
and indeed
in my test workspace they are found, but the settings are not attached to the files outside the project
that triggered
the build.
Thanks
Fabrizio
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev