Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Adding non-primary outputs to resource tree

I am currently building using the internal builder.  When I do a manual refresh all the files show up, I think you are right about the internal builder trying to be smart about refreshing resources. With the patch I have proposed I can get all the outputs to appear in the workspace.  Is there a concern that allowing secondary output types to be discovered for a target tool will cause problems?

 

I am not sure what happens with a makefile build at the moment, I’m concentrating on getting the internal builder working first and then worry about the makefile builder (I’m representing a somewhat non-standard toolchain!).

 

As an aside… The reason I need all the outputs to appear is that although the primary output is useful, there are secondary outputs that also have value and are used as inputs to other projects.  If they are not represented in the workspace then I can’t use workspace relative references to them.

 

Regards,

Matthew

 


From: 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 refreshed.

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.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

Inactive hide details for "Matthew Fortune" ---06/22/2010 07:31:56 AM---Ed/any,"Matthew Fortune" ---06/22/2010 07:31:56 AM---Ed/any,


From:


"Matthew Fortune" <Matthew.Fortune@xxxxxxxxxx>


To:


"CDT General developers list." <cdt-dev@xxxxxxxxxxx>


Date:


06/22/2010 07:31 AM


Subject:


RE: [cdt-dev] Adding non-primary outputs to resource tree


Sent by:


cdt-dev-bounces@xxxxxxxxxxx





Ed/any,

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

If that makes sense then the patch is attached! Is this a sensible change?

Regards,
Matthew


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


Hi Ed,

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

[[ejs]] 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.

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

It isa 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 work.

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

Regards,
Matthew

-- Ed

[attachment "BuildDescription_outputtypes.patch" deleted by Chris Recoskie/Toronto/IBM] _______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top