Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Is the Binary Parser a project or build property

> -----Original Message-----
> From: Douglas Schaefer [mailto:dschaefe@xxxxxxxxxx]
> Sent: September 17, 2003 8:58 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] Is the Binary Parser a project or 
> build property
> 
> 
> My point is that the user shouldn't have to care about the 
> binary parser. 
> It would be best to make things as automatic as possible.
> 
> And, yes, I would think that if you are developing with 
> Windows as host 
> and RTOS as a target, you would run into cases where you are 
> building for 
> both (i.e. Windows for Sim/Testing).  We certainly have in the past.

Late to the conversation ... but just back from a customer site where
one of their complaints was the fact that they had a "unified" build
structure where they would build binaries for Windows/VxSimulator/QNX
all from the same source base and have it all live in the same tree.

The fact that there was only one binary parser available for a project
kind of caught them unawares and actually in some cases cause Eclipse
heartburn as we tried to parse things we didn't understand.

Thomas

> "Alain Magloire" <alain@xxxxxxx> 
> Sent by: cdt-dev-admin@xxxxxxxxxxx
> 09/17/2003 05:45 PM
> Please respond to
> cdt-dev@xxxxxxxxxxx
> 
> 
> To
> cdt-dev@xxxxxxxxxxx
> cc
> 
> Subject
> Re: [cdt-dev] Is the Binary Parser a project or build property
> 
> 
> 
> 
> 
> 
> > 
> > I would think it's a build thing since the setting depends on what 
> target 
> > you are building for.  Standard Make doesn't know what the 
> target is so 
> > the user has to set it.
> > 
> > Having said that, I would consider it a Resource setting, since you 
> should 
> > be able to do multi-target builds with the CDT meaning 
> you'll have the 
> > build results for different targets available in the same 
> project.  I 
> 
> Good point, we do not.  If you have a project that is a mix of say
> DOS executables and GNU/Linux binaries ... it can be problematic.
> Something to add in the long list of 2.x pool requests?
> 
> But is that a high runner case?  Are we putting flexibility where
> there is no need?
> 
> Double personalities will produce psychotic behaviour 8-).
> We have this all over CDT;
> Parser:  C vs C++
> Builder:  Debug vs Release
> 
> etc ..
> 
> > don't think we really handle that situation today (at least 
> not in a 
> user 
> > friendly way).  Having said that (...) I don't see why we 
> can't detect 
> the 
> > type of binary by just looking at it.  Most binary formats 
> I know of 
> have 
> > some magic bits at the beginning to tell you what it is (or 
> am I wrong? 
> > It's certainly true with PE).
> 
> It is more then that, Binary Parser can do much more: make a 
> distinction
> between shared libraries, object, executables, archives, 
> core. We could 
> parse binaries
> to find symbol, line numbers etc ....  The entire framework is not in 
> place
> yet to make good use of it, 2.x material.
> 
> For PE, unfortunately, things are not moving much.  It is not 
> a format 
> that
> we work on everyday.
> 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> 


Back to the top