Re: [cmake-developers] Better Eclipse CDT support

2011-05-09 Thread Manuel Klimek
On Sun, May 8, 2011 at 7:38 PM, Oliver Buchtala oliver.bucht...@jku.at wrote:
 Hi Alex, Manuel, and other interested watchers,

 I'd like to introduce a preview version of an Eclipse plugin
 'CMakeWorkbench' which is combined with the CMake CDT7 generator
 developed lately.
 I try to reduce user actions for importing projects and managing working
 sets.
 By watching solution files generated with CDT7 generator automatic
 updating is achieved...
 Of course there are still some hitches... and obviously much space for
 improvement... but hey ;) that's is my first eclipse plugin

 Please find notes about installation:
 https://github.com/oliver/cmake-workbench/blob/master/doc/Install.markdown
 and a step by step HelloWorld on:
 https://github.com/oliver/cmake-workbench/blob/master/doc/examples/HelloWorld.markdown

 Please: I'd like to have your opinion and maybe some trying :)

First impression: very nice.

Somehow even the .h stuff works now :)

/me is happy... will use it more and see how it behaves when the
CMakeLists.txt change :D

Cheers,
/Manuel


 Bye,
 Oliver

 PS: I have developed and tested under Ubuntu LTS 10.04 + Eclipse 3.7 M6
 + CDT 8.0 M6.


___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] Better Eclipse CDT support

2011-05-09 Thread Manuel Klimek
On Mon, May 9, 2011 at 2:30 PM, Manuel Klimek kli...@google.com wrote:
 On Sun, May 8, 2011 at 7:38 PM, Oliver Buchtala oliver.bucht...@jku.at 
 wrote:
 Hi Alex, Manuel, and other interested watchers,

 I'd like to introduce a preview version of an Eclipse plugin
 'CMakeWorkbench' which is combined with the CMake CDT7 generator
 developed lately.
 I try to reduce user actions for importing projects and managing working
 sets.
 By watching solution files generated with CDT7 generator automatic
 updating is achieved...
 Of course there are still some hitches... and obviously much space for
 improvement... but hey ;) that's is my first eclipse plugin

 Please find notes about installation:
 https://github.com/oliver/cmake-workbench/blob/master/doc/Install.markdown
 and a step by step HelloWorld on:
 https://github.com/oliver/cmake-workbench/blob/master/doc/examples/HelloWorld.markdown

 Please: I'd like to have your opinion and maybe some trying :)

 First impression: very nice.

 Somehow even the .h stuff works now :)

No, it doesn't ... It now opens the projects in the background (which
is nice) and had me thinking that there were no duplicated .cpp files
in there any more for a moment.


 /me is happy... will use it more and see how it behaves when the
 CMakeLists.txt change :D

 Cheers,
 /Manuel


 Bye,
 Oliver

 PS: I have developed and tested under Ubuntu LTS 10.04 + Eclipse 3.7 M6
 + CDT 8.0 M6.



___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] Better Eclipse CDT support

2011-05-09 Thread Oliver Buchtala
Am 09.05.2011 23:32, schrieb Manuel Klimek:
 On Mon, May 9, 2011 at 2:30 PM, Manuel Klimek kli...@google.com wrote:
 On Sun, May 8, 2011 at 7:38 PM, Oliver Buchtala oliver.bucht...@jku.at 
 wrote:
 Hi Alex, Manuel, and other interested watchers,

 I'd like to introduce a preview version of an Eclipse plugin
 'CMakeWorkbench' which is combined with the CMake CDT7 generator
 developed lately.
 I try to reduce user actions for importing projects and managing working
 sets.
 By watching solution files generated with CDT7 generator automatic
 updating is achieved...
 Of course there are still some hitches... and obviously much space for
 improvement... but hey ;) that's is my first eclipse plugin

 Please find notes about installation:
 https://github.com/oliver/cmake-workbench/blob/master/doc/Install.markdown
 and a step by step HelloWorld on:
 https://github.com/oliver/cmake-workbench/blob/master/doc/examples/HelloWorld.markdown

 Please: I'd like to have your opinion and maybe some trying :)
 First impression: very nice.

 Somehow even the .h stuff works now :)
 No, it doesn't ... It now opens the projects in the background (which
 is nice) and had me thinking that there were no duplicated .cpp files
 in there any more for a moment.

Yepp. This is still an issue.
I filed issues on CDT and reopened the corresponding issue on my github.
I hope I find a clean solution soon.

Basically, I don't like my approach to have a link to the full tree.
Causes trouble and brings redundancy.

Hopefully, they (CDT gang) try to work on the Ctrl-Shift-R for includes.
I will try to add more linked resources (e.g., flex input sources etc.)
Linked folders raise so many problems right now :(

Don't hesitate to add ideas, feelings, suggestions  by means of issues
or comments on my github :)

Cheers,
Oliver

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] [CMake 0012171]: Runpaths incorrect for all hpux/pa_risc systems

2011-05-09 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=12171 
== 
Reported By:Peter O'Gorman (The Written Word, Inc.)
Assigned To:
== 
Project:CMake
Issue ID:   12171
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2011-05-09 23:07 EDT
Last Modified:  2011-05-09 23:07 EDT
== 
Summary:Runpaths incorrect for all hpux/pa_risc systems
Description: 
Installing a build with shared libraries on this system causes builddir runpaths
to be coded into the installed shared libraries and executables.

e.g.

/opt/TWWfsw/libproxy04/lib/libproxy.sl:
 shared library
 shared library dynamic path search:
 SHLIB_PATH disabled  second
 embedded path  enabled   first  /opt/TWWfsw/libproxy04/lib:/usr/lib
 internal name:
 libproxy.sl.1
 shared library list:
 static   
/opt/build/libproxy-0.4.6/libproxy/../libmodman/libmodman.sl.1
 dynamic   /usr/lib/libnsl.1
 dynamic   /usr/lib/libcma.2


Because ld is invoked with a command like
aCC -o /path/to/libproxy.sl.1  ../libmodman/libmodman.sl.1 

The library is added and its type is set to static, this means that the RPATH
and env vars have no effect, if the library does not exist at
/opt/build/libproxy-0.4.6/libmodman/libmodman.sl.1 the executable will abort.

Steps to Reproduce: 
Build libproxy on HP-UX/PA 32bit. (the 64 bit linker behaves differently).

Additional Information: 
Attached is the hack that we used to let hpux builds use -L.. -lfoo, which makes
the entry dynamic so that SHLIB_PATH and the RPATH can have a chance to work.
This includes a hack to the install to add -L flags for every path in RPATH
prior to other -L paths, this allows us to do 'make install' then rm all the
relinked binaries in the build dir, do 'make install' again and have no
references to the build dir appear in the installed libraries, because the
second relink will use the installed libraries.

Relinking happens in a 'preinstall' rule, and I don't know how to move it to an
install rule. If it were in the install: rule then it would work well. Assuming
that cmake installs things in dependency order (it appears to, but I don't know
if that is guaranteed), we would, for libproxy for example, relink libmodman,
install libmodman, relink libproxy using the installed libmodman, install
libproxy, relink the 'proxy' utility using both installed libraries, install
proxy, and all the embedded paths would be correct. Time permitting, I will
continue to look at fixing this properly.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-05-09 23:07 Peter O'Gorman (The Written Word, Inc.)New Issue   

2011-05-09 23:07 Peter O'Gorman (The Written Word, Inc.)File Added:
cmake.hack.patch
==

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] [CMake 0012172]: [PATCH] FindRuby does not find ruby-1.9.1 shipped with (k)ubuntu

2011-05-09 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=12172 
== 
Reported By:Luiz Angelo Daros de Luca
Assigned To:
== 
Project:CMake
Issue ID:   12172
Category:   Modules
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2011-05-09 23:12 EDT
Last Modified:  2011-05-09 23:12 EDT
== 
Summary:[PATCH] FindRuby does not find ruby-1.9.1 shipped
with (k)ubuntu
Description: 
Hello,

FindRuby only found the 1.8.6 version of my ruby installation, even if I force
the RUBY_EXECUTABLE name.

Steps to Reproduce: 
install ubuntu
install both ruby1.8-dev and ruby1.9.1-dev

Use in cmake:

FIND_PACKAGE( Ruby REQUIRED )
SET( RUBY_EXECUTABLE ruby1.9.1 )

It did not find the ruby library. because it misses a - and it does not use
full version. Also, RUBY_EXECUTABLE is not an common input. My config is kind of
a hack but the fix is still valid.

Additional Information: 
I did a patch to fix this issue when library is libruby-1.x.x.

I also noticed that there is both RUBY_MAJOR_VERSION and RUBY_VERSION_MAJOR. Is
it all right?

Also, some parameters use Ruby_XXX form instead of RUBY_XXX. I guess the default
in cmake should be the latter (but it will break previous uses).

At Last, if I have multiple ruby installations, I cannot simply set:

(Ruby_FIND_VERSION 1.9)

This should be the easiest solution. However, I'm no expert in cmake lang.

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-05-09 23:12 Luiz Angelo Daros de LucaNew Issue 
  
2011-05-09 23:12 Luiz Angelo Daros de LucaFile Added: find-ruby-library.patch   

==

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers