cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
Sent: 22 June 2010 15:30
To: CDT General developers list.
Subject: RE: [cdt-dev] Adding
non-primary outputs to resource tree
Question: are you building via a generated makefile,
or using the internal builder? I can't remember but it's possible that the
internal builder tries to be a little too smart about what resources it
refreshes. The thing to check is whether your map file shows up after you
manually refresh the folder. If not, then it's an oddity of what the Project
Explorer is filtering as opposed to an issue of the outputs not being properly
As far as I know the reason it ignores secondary outputs is that they are not
needed for dependency calculation. They are side effects of your build as
opposed to the main artifact that your build outputs (which typically is an
executable or library). Thus, you don't want to create makefile rules for them.
Team Lead, IBM CDT and RDT
Fortune" ---06/22/2010 07:31:56 AM---Ed/any,
developers list." <cdt-dev@xxxxxxxxxxx>
06/22/2010 07:31 AM
Adding non-primary outputs to resource tree
out that calculateOutputs in BuildDescription does take in to account the
output types for each tool, but it is a little inconsistent… Essentially
it will ignore all but the primary output of the target tool. I don’t
know if this is intentional or a bug but I have changed the logic to process
the primary output of a target tool using the toolchain’s
artifact+extension and then continue on to process all the non-primary outputs
of a target tool in the same way as it does for non-target tools.
makes sense then the patch is attached! Is this a sensible change?
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Matthew Fortune
Sent: 21 June 2010 21:56
To: CDT General developers list.
Subject: RE: [cdt-dev] Adding non-primary outputs to resource tree
> I am integrating a linker
that can emit a map file alongside the primary output (an ELF binary). I would
like the file to appear in the workspace and assumed that representing it using
an outputType would accomplish that.
> Am I correct to think
that additional outputs should appear as resources when the build completes or
do I need to implement something else?
Any outputs that go into the project's directory tree should show up in their
appropriate locations as a result of the "refresh resources" task
that follows a build.
suspect either your binaries are built outside a project, or too deep inside
it, and you want the *.map file to show upin the top level Binaries folder next
to your ELF binary. Is that it? The "binary parser" facility is used
to promote content there (see Project > Properties> C/C++ Build >
Settings > Binary Parsers). The project view doesn't use the
"outputType" attribute, AFAIK.
The binaries and map file are
being output directly to the output folder (<project>/[Release|Debug]).
Whilst the intermediate object files and binaries appear in the Debug or
Release folder in the resources view the map file does not (and I did check it
was created!). I will however see if I can trace through the ‘refresh
resources’ task and figure out if there is some subtlety (I assume I will
find that in the cdt source relatively easily).
nasty hack, and 50% a joking suggestion, but you could implement a
"binary" parser that detects map files and register that with your
toolchain. See the 'org.eclipse.cdt.core.BinaryParser' extension point and the
corresponding MBS stuff which I don't know. (This may have unintended
consequences, though, such as suddenly being able to launch map files with the
debugger... I'm not sure on this point ;)
Maybe if I get really
desperate! I have to assume I am doing something very wrong if this should just
than that, I think the Common Project Navigator (e.g. "Project
Explorer" view) provides extensions that let you add content, likevirtual
folders, to a project as well. You may look into that option as well, but
that's an Eclipse platform feature and not a CDT one.
Thanks for the tips,
I’ll post back when I have dug a bit deeper.
deleted by Chris Recoskie/Toronto/IBM] _______________________________________________
cdt-dev mailing list