Skip to main content

[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"

On 18 November 2010 10:44, Christian Walther <walther@xxxxxxxx> wrote:
> 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 ...

To be clear that was a core.resources bug - we put a workaround in
7.0.1 to stop CDT from hitting it :).

> I guess that would more or less correspond to the Visual Studio/Xcode/...
> solution where project contents and file system layout are completely

We did a fair bit of work on this for a group migrating from VS.  I
believe we achieved parity, pulling source in from anywhere using
linked resources.  ManagedBuild resolves and builds the source files
correctly and if something doesn't work, it's a bug.  There is only
one gotcha to this approach (that I know of): while source files can
be linked to anywhere, for -Is the links should be at the directory
level  as the option passed to the compiler is a directory.  This
means you can't pull in .h's directly with links.
We could always fix this by faking up a temporary directory on the
filesystem containing a real instantiation of the virtual resources.
However we didn't need this so never implemented this.

> 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.

This certainly used to be the case. However a whole load of bugs were
fixed in this area...

> 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.

We do something similar.  We have a number of different processor
cores to support.  In general we've been able to pull out the features
from the hardware specific bits to make the two effectively
orthogonal.  So in our IDE we let users choose a system chip type,
separate from a SDK version.  CDT then 'magically' pulls in the
correct include/library/pre-proc defines for the combination of chip +
sdk_ver.  They can select which SDK features they final program
they're building wants, which translates to linking against the
various libraries.

If you can split the problem along these lines then you may be able to
avoid the nightmare of a large matrix containing every possible
combination of feature and platform.  Apart from anything else, if you
can model it as CDT configurations then the indexer, code navigation,
etc. have a hope of working.

Another thing you can do is modularize the software and put the
orthogonal parts in different CDT projects with references between the
configurations.  We've scaled this to an 80 project, project set now
(and with the upcoming build configuration platform improvements) it
performs really well.

> 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).

It's interesting that you build the low-level files each time rather
than building them once into a SDK and linking against them.  We do
the latter releasing and versioning the common components, and getting
eclipse to dynamically link against them.

Cheers,
James


Back to the top