Re: [ptp-user] Include and library paths for a combined C and C++ synchr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

Re: [ptp-user] Include and library paths for a combined C and C++ synchronized project

From: Beth Tibbitts <tibbitts@xxxxxxxxxx>
Date: Fri, 4 Jan 2013 17:05:29 -0500
Delivered-to: ptp-user@xxxxxxxxxxx
List-archive: <https://dev.eclipse.org/mailman/private/ptp-user>
List-help: <mailto:ptp-user-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/ptp-user>, <mailto:ptp-user-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/options/ptp-user>, <mailto:ptp-user-request@eclipse.org?subject=unsubscribe>

Also, we determined for the SC12 tutorial that for synchronized projects you should *not* use the "remote" toolchains.
If you can get it to work with them, that's fine. There were some differences that i think we still need to work out, but 'remote' toolchains "should not" be needed.

See the SC12 tutorial slides for what we determined to work the best.
http://wiki.eclipse.org/PTP/tutorials/SC12
Note you need the CDT remote includes fix - also available on that link above. and in the slides too. to the the "//connection/path/to/include' to work

...Beth

Beth Tibbitts
Eclipse Parallel Tools Platform http://eclipse.org/ptp
IBM STG - High Performance Computing Tools
Mailing Address: IBM Corp., 745 West New Circle Road, Lexington, KY 40511

John Eblen ---01/04/2013 04:31:19 PM---Hi Dave For synchronized projects, you need to prepend the connection name to

From:	John Eblen <jeblen@xxxxxxx>
To:	PTP User list <ptp-user@xxxxxxxxxxx>,
Date:	01/04/2013 04:31 PM
Subject:	Re: [ptp-user] Include and library paths for a combined C and C++ synchronized project
Sent by:	ptp-user-bounces@xxxxxxxxxxx

Hi Dave

For synchronized projects, you need to prepend the connection name to
include paths for remote includes. For example, if the connection name is
"carver" and you wish to include /usr/include on carver, type the following:

//carver/usr/include

The help for synchronized projects contains more information on handling
remote include paths.

BTW, we are currently developing a method for automatically detecting
remote include paths. So this capability will be available in a future release.

John

On Fri, Jan 4, 2013 at 4:10 PM, Dr. David E Hudak <dhudak@xxxxxxx> wrote:

Hi Jay,

In this particular test case, eclipse
1. successfully indexes a C++ file and resolves all symbols for a remote project
2. fails to resolves all symbols for a synchronized project

Some background:
For the remote project, I created the project as a Remote GCC C/C++ Executable with a Remote Linux GCC Toolchain.
I added the source file.
Then I added to project properties:
a. Include paths
b. Library paths
c. Library flags

The project builds and symbols resolve.

For the synchronized project, I created the project as an Empty Makefile project with a Remote Linux GCC toolchain.
I added the source file and the makefile
Then I added include paths

I suspect the problem is in the files being used for indexing. The remote project automatically includes a bunch of remote header files. The synchronized project automatically includes local header files which (a) may be of the wrong version or (b) may omit necessary includes on the server side.

Thanks,
Dave
On Jan 3, 2013, at 11:53 AM, "Alameda, Jay" <

alameda@xxxxxxxxxxxx

> wrote:

> Dave,
>
> I think one of the motivators (among many) for developing synchronized projects was to improve indexing -- but of course, this is complicated with the remote include path issue - so I don't think I'm surprised by the differences in indexing between remote and synchronized project types. However, I'd hope that indexing for synchronized projects was better than indexing for remote projects, do you know if this is the case?
>
> Jay
>
>
> -----Original Message-----
> From:

ptp-user-bounces@xxxxxxxxxxx

[mailto:

ptp-user-bounces@xxxxxxxxxxx

] On Behalf Of Dr. David E Hudak
> Sent: Monday, December 24, 2012 10:08 AM
> To: PTP User list
> Subject: Re: [ptp-user] Include and library paths for a combined C and C++ synchronized project
>
> Hi All,
>
> After some more work, I have gotten the issue resolved! Unfortunately, it seems that there are some differences in the behavior of indexing for C projects between remote projects and synchronized projects. If people are interested, I can study it further. Let me know.
>
> Thanks,
> Dave
> On Dec 18, 2012, at 5:42 PM, Dr. David E Hudak <

dhudak@xxxxxxx

> wrote:
>
>> Hi All,
>>
>> I am working with a colleague who is trying PTP for a C/C++ project that uses OpenSlide and OpenCV (computer vision). I have a question regarding setting the appropriate include paths, library paths and libraries.
>>
>> He currently has a makefile on the remote system (Oakley, one of our linux clusters) that he is able to build his example source code with.
>>
>> First, I had him create an empty Makefile project with the remote GCC toolchain, no local toolchain. In order for eclipse to resolve the program's symbols, I had him add the remote include paths:
>> //oakley/nfs/14/samsi/devel/opencv-2.4.2/include/opencv
>> //oakley/nfs/14/samsi/devel/opencv-2.4.2/include
>> //oakley/nfs/14/samsi/devel/openslide-3.3.2/include/openslide
>>
>> And, there was a symbol, Mat, that was not resolved by eclipse but is found when the makefile runs (many other symbols were resolved). The main code file has:
>> #include <cv.h>
>> where cv.h is a bunch of other includes, particularly:
>> #include "opencv2/core/core.hpp"
>> and the class in question, Mat, is defined in core.hpp.
>>
>> I have tried to add opencv2 to the include paths and <core/core.hpp> to the main code, but that did not work. The only other symbols that were not resolved were declared in C header files underneath opencv2.
>>
>> Second, I had him create a synchronized project of type "Executable/Empty Project", again with GCC remote tools and no local tools. We added the include paths:
>> /oakley/nfs/14/samsi/devel/opencv-2.4.2/include/opencv
>> //oakley/nfs/14/samsi/devel/opencv-2.4.2/include
>> //oakley/nfs/14/samsi/devel/openslide-3.3.2/include/openslide
>> ...and we added the library paths:
>> //oakley/nfs/14/samsi/devel/opencv-2.4.2/lib
>> //oakley/nfs/14/samsi/devel/openslide-3.3.2/lib
>> ...and we added the libraries
>> opencv_core
>> opencv_highgui
>> openslide
>>
>> But, when I did that, the auto generated makefile had the connection prefix //oakley in the -I and -L commands! I went back to the project properties and removed them, and then the auto generated makefile worked. However, the symbol resolution was broken in this project after I changed the include paths.
>>
>> So, after that long explanation, here are my questions:
>> 1. Are there any good rules for include paths for combined C and C++ projects? I take it eclipse is not a thorough as the compiler in spelunking through include files being included by other include files?
>> 2. For the auto generated makefile, what is the appropriate way to declare remote library and include paths?
>> 3. How can the local include paths for things like /usr/local be replaced with remote include paths?
>>
>> Thanks,
>> Dave
>> ---
>> David E. Hudak, Ph.D.

dhudak@xxxxxxx

>> Senior Research Scientist
>> Ohio Supercomputer Center
>>

http://www.osc.edu

>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> ptp-user mailing list
>>

ptp-user@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/ptp-user

>
> ---
> David E. Hudak, Ph.D.

dhudak@xxxxxxx

> Senior Research Scientist
> Ohio Supercomputer Center
>

http://www.osc.edu

>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> ptp-user mailing list
>

ptp-user@xxxxxxxxxxx