On Jan 7, 2008 6:16 PM, Mario Charest <mcharest@zinformatic.com> wrote:

> > Are you using Managed Projects?
> >
> > Check the project configuration. Make sure you have QNX Binary Parser
> > enabled. Project->Properties... C/C++ Build->Settings->Binary parsers
> tab
> > (and disable others if you have them)
> >
>
> That did it, thanks!  It's still slow while browsing from tab to tab, but
> I can live with that.
>
I don't think that I can live with that.  We should be able to short circuit
what ever work we
are doing on tab/configuration changes.

Is the binary particularly large, or just 'across the network'?  Anything
else that is particular
that we could use to ferret out the issue .. which will likely be on the CDT
side of the world.

Thanks,
 Thomas

Good lord!
Now I have tried (with my recent "success" fresh on my mind) to create a new project.

This time, since I selected a project type of "Standard C++ Makefile", instead of "Standard C Makefile" project, AND I 
imported the executable into the project (which seems to have worked by eliminating the Program Not Found message)

Now I can no longer select the QNX GDB debugger

No matter which debugger I select, Cygwin, gdb, gdb/mi or gdbserver, I get a popup message that says "Invalid debugger 
type"

So if I use C++ syntax in much of the code, must I select a C++ Makefile?
Perhaps a Standard C Makefile, which apparently brings the QNX gdb debugger with it by default, is good enough?

The bad news is that even after building a new project with Standard C Makefile as its type, I STILL can't see the QNX 
GDB Debugger and still get the same invalid debugger type error.

AAARRRGGHHH!

Suggestions?

- Frank

Hello Frank,

Would you kindly start a separate thread (which a reference to this one ). Because my guess is the causes of the problem
 are different then mine and it's going to make the thread hard to follow.

Kind regards,

Mario

> > Are you using Managed Projects?
> > 
> > Check the project configuration. Make sure you have QNX Binary Parser
> > enabled. Project->Properties... C/C++ Build->Settings->Binary parsers tab
> > (and disable others if you have them)
> > 
> 
> 
> I am having a similar problem.
> I get a "[Main]: Program not found" message, and I have tried to follow your 
> instructions. 
> 
> I  found a Binary Parsers tab and the QNX binary parser is the only one 
> enabled. 
> 
> What is very mysterious is that this project used to be debuggable.
> I started trying to debug a DIFFERENT application (with a new project) and got
>  this error message. I hacked on the 2 project configurations to try and see 
> what the difference between them was. During the hacking around, something 
> changed (accidentally?) and suddenly neither of the projects were debuggable.
> 
> While I continued my trial and error session to find the reason for the 
> problem, the debug button lit up (even though the error message was still 
> there). I expected that the debug session would start with no source visible, 
> but instead the debug session tried to start and then a new message box popped
>  up saying there had been a timeout when trying to activate the code coverage 
> tool (which I didn't want nor had I enabled). 
> 
> Sadly (or happily, depending on your viewpoint) now I can't replicate this 
> problem. 
> I finally arrived at this conclusion:
> 
> Under C/C++ Application in the main tab of the debug configuration, if I 
> Search the project for the executable file, the error message goes away. If I 
> browse directly to the target file system to find THE SAME DAMN FILE, the 
> error message persists and prevents debugging.
> 
> I have no problem with this state of affairs except that after I have built 
> this project over and over again to try and get to this point, I am completely
>  stumped as to how the executable made it into the project. In the other 
> versions of this project, when I selected "Search Project" the underlying 
> screen came up blank.
> 
> What is further confounding is that SOMETIMES (I don't know how) SOME versions
>  of the project allowed me to browse directly to the target file system and 
> debug just fine.
> 
> I think there are some problems with this strategy of using the target system 
> as the build platform and just debugging from Momentics, but I have no choice 
> in my case. I can't put a Momentics style project make together until after I 
> migrate the existing code (a huge body of code with a hand-crafted Makefile 
> that is not Momentics friendly).  I wish you guys had a GOOD step by step 
> tutorial that covered this type of project use. The toy projects you provide 
> showing "Hello World", and various applications of semaphores and MUTEXes are 
> interesting, but are pretty much self-evident. 
> 
> The problems that one encounters migrating large applications from Linux to 
> QNX are NOT!!
> 
> Now what was my question, again??? Oh yeah, how does one make sure the binary 
> executable ends up in the project?
> 
> Thanks - Frank

On Jan 9, 2008 5:01 PM, Frank Rudolph <rudolph@beaconpower.com> wrote:

[ Tales of woe and frustration with the debugger & code coverage launch
snipped ]


> I think there are some problems with this strategy of using the 
target
> system as the build platform and just debugging from Momentics, but I have
> no choice in my case. I can't put a Momentics style project make together
> until after I migrate the existing code (a huge body of code with a
> hand-crafted Makefile that is not Momentics friendly).  I wish you guys had
> a GOOD step by step tutorial that covered this type of project use. The toy
> projects you provide showing "Hello World", and various applications of
> semaphores and MUTEXes are interesting, but are pretty much self-evident.
>
> The problems that one encounters migrating large applications from Linux
> to QNX are NOT!!
>
I run into developers who feel the same frustration over and over again ...
until they realize that the problem(s) are
really only _partially_ an IDE problem.

Perception #1: I need to convert my build to a "Momentics style project" to
use the IDE

Reality:  The IDE wants you to narrow down the scope of what it needs to
know about (source, binaries etc) so you need to create
a project _associated_ with your source/binaries and this project is in turn
_associated_ with a workspace.  This project doesn't have
to be in the workspace, it can be anywhere you want it to be.  Here are some
options:
* Source lives in a project which lives in the workspace.  This is the
default when you create a new project or bring source into the
IDE using Import from filesystem (which _can_ do a copy, but doesn' t have
to) or using a version control plugin

* Source lives somewhere in the filesystem and we want to overlay a project
at that location.   You can achieve this by creating a
project and changing the default location from the workspace to the location
of the source.

* Source lives somwhere in the filesystem, but we don't want to create any
metadata files in that location.  In that case, create a
project (in the workspace or elsewhere as in the previous scenario) that is
empty. Then create a folder in that project and make
the folder location 'point' to the source in the filesystem using the
>>Advanced section of the dialog.  This is like a unix symlink,
but exists only in the IDE workspace.

... but what project do I choose you ask?

 Perception #2: I need to convert my build process to match an IDE project

Reality #2:  The process of selecting a project type appears more
complicated than it is.  For _nearly_ every type of existing
code with a build process, you will want to choose the "Standard C (or C++)
Make Project" type.  Why?  Because this project type
just calls out to some external build program to build the source.  Most of
the time this is 'make', hence the name of the project,
but it could be JAM, ANT, dmake, cons or any other builder.

If you have the luxury of starting your project from scratch, then the QNX
Projects are interesting because they allow you to
build multiple processors (more generally 'variants', including OS'es) with
a single build based on the QNX recursive make
framework.  They won't 'port' well to other systems however.  Managed Make
Projects are interesting because they provide
a full IDE graphical control and configuration, familiar to those coming
from Visual Studio, and can really take advantage of
the Eclipse frameowork (ie incremental compiles, links etc) but are still
relatively immature.

... and if you are never going to run your build from the IDE (I never say
never), then the choice is even simpler: Standard Make
all the time just to identify the source as "C/C++" source and help identify
the binary types.

Perception #3: Nothing is showing up anywhere, this IDE thing is totally
_busted_!

Reality #3:  Since one of the goals of...