Re: [cdt-dev] Programmatically excluding files from build "on-the-fly"

[James Blackburn <jamesblackburn@xxxxxxxxx>]

On 11 November 2010 16:33, Christian Walther <walther@xxxxxxxx> wrote:
> This appears to work, but has a few disadvantages (not deal-breakers, but
> maybe there's a way of avoiding them):
>
> - The source folders are persisted in the .cproject file, which means this
> file changes every time our subset changes (actually, it currently doesn't
> do that reliably, but that's something I need to fix, but haven't figured
> out how yet), creating unwanted diffs in version control. For our purposes,
> this information is redundant and doesn't need to be stored, since it is
> regenerated (from information stored elsewhere) on every build.
>
> - Overwriting the "exclude from build" settings / source folders and exclude
> patterns means that users can't use them for their own purposes anymore, as
> their manual modifications will be wiped out at the next build. This is
> confusing at best and a loss of functionality at worst.
>
> Is there a better way of achieving what I want? Ideally I would like to hook
> into the CDT makefile generator and tell it which files to consider on the
> fly, without clobbering any persistent user settings, but I haven't found
> any extension point that would allow me to do that - and replacing the
> entire thing looks like a daunting task.

There are a couple other ways to do this.  The Platform core.resources
now has filtering so you can add / exclude source at the resource
layer.  See the org.eclipse.core.resources.filterMatchers extension
point and API on IWorkspace.  You can define your own filter hook
which is invoked.

Another way might be to add an eclipse linked resource to the
directory(ies) from a place within a CDT source directory to the place
where your source is located.

Both of the above may touch the .project to a greater or lesser extent
- though with your own filter hook, this should be limited the first
time the hook is defined.

Given that you're building different sets of source, why don't you
just model this with CDT build configurations?

I guess it's difficult to pick out the best way of doing this without
knowing a bit more about how this source comes in and out of
existence.

Cheers,
James