[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Programmatically excluding files from build "on-the-fly"
|
James Blackburn wrote:
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.
I was under the impression that these weren't properly supported by
CDT yet (https://bugs.eclipse.org/bugs/show_bug.cgi?id=317783), but
now I see that this is fixed in CDT 7.0.1, so I will have another
look. The idea of a filter hook sounds appealing.
The difference to the exclude-from-build/source-path solution would be
that in the latter, the excluded files are still visible in the
project tree, which I kinda liked, but that is not a requirement (and
might even be considered a disadvantage by others).
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.
I guess that would more or less correspond to the Visual Studio/
Xcode/... solution where project contents and file system layout are
completely independent (which is actually what we're doing in our
legacy IDE that is to be superseded by the Eclipse-based one). I was
shying away from this because it seems to go against the grain of the
Eclipse philosophy, and also based on a general vague (and admittedly
not well-founded) impression (from reading mailing lists and bugzilla
entries) that linked resources are some kind of second-class citizens
in Eclipse.
Given that you're building different sets of source, why don't you
just model this with CDT build configurations?
That's an interesting idea, but I think it's not a good match for our
requirements because the subsets of files to be built are too diverse.
We will basically have a row of checkboxes "Use feature A", "Support
hardware B", ... that each causes some files to be added to the build,
and making a separate configuration for every possible combination of
checkboxes looks unwieldy. We may also need to keep the configurations
orthogonal to the selection of the source subset, e.g. to switch
between "debug" and "release" builds.
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.
The files form the operating system for an embedded system and are
compiled together with user application code into a single binary.
Depending on what hardware needs to be supported and what OS features
the user wants, different subsets of OS files need to be built. The
files come into existence by being checked out from a Subversion
repository that always contains files for all hardware devices and
software features (some of them conflicting). We can't just delete the
files that aren't needed because the next "svn update" would bring
them back. Such an update may also add new files, along with feature
definitions that determine under what circumstances they are to be
included in the build, and the user should then immediately be able to
select (or deselect) these new features without having to recreate or
otherwise manually adjust the project.
Thank you for these suggestions! Very helpful. I will investigate the
resource-filter solution now and then probably settle on either that
or the source-path-exclusion solution.
-Christian
