Rodolfo Lima wrote:
Michael Wild escreveu:
I once wrote a cmake-macro which created these symlink trees (only for
the headers, though). It was a huge PITA. With such symlink trees you
can never be really sure that they are consistent with the source tree.
I think I'm convinced now. The truth i
Michael Wild escreveu:
> I once wrote a cmake-macro which created these symlink trees (only for
> the headers, though). It was a huge PITA. With such symlink trees you
> can never be really sure that they are consistent with the source tree.
I think I'm convinced now. The truth is: I've always wor
On Thu, 03 Dec 2009 18:17:21 -0200, Rodolfo Schulz de Lima
wrote:
> How does emacs know all the project files? Or it is only looking
> backwards on the include list (this would only find header files)?
M-x visit-tags-table
I have a cmake command to generate tags in the *source* directory, I run
On 3. Dec, 2009, at 23:23 , Rodolfo Lima wrote:
John Drescher escreveu:
install screen
Thanks for the tip but that's not my point in this whole thread (i.e.
I'm not looking for solutions, I'm giving one).
CMake does so much complicate things to make working with software
projects a seamless
Andreas Pakulat escreveu:
> That doesn't work good enough. CMake doesn't prohibit referencing files
> from all over the project tree, so if I update foo/CMakeLists.txt, that
> might need symlink changes over at bar/... So a complete tree-update
> is needed unless CMake wants to keep track of the "l
On Thu, Dec 3, 2009 at 5:55 PM, Bill Hoffman wrote:
> Rodolfo Lima wrote:
>
>> John Drescher escreveu:
>>
>>> install screen
>>>
>>
>> Thanks for the tip but that's not my point in this whole thread (i.e.
>> I'm not looking for solutions, I'm giving one).
>>
>> CMake does so much complicate things
Rodolfo Lima wrote:
John Drescher escreveu:
install screen
Thanks for the tip but that's not my point in this whole thread (i.e.
I'm not looking for solutions, I'm giving one).
CMake does so much complicate things to make working with software
projects a seamless experience across different p
On 03.12.09 18:03:56, Rodolfo Schulz de Lima wrote:
> Andreas Pakulat wrote:
> > See my other mail, there's no way for cmake to find out which symlinks
> > are dead links, except by scanning all source files on a cmake run.
> > Thats a huge waste of time, especially on bigger projects with a few
>
On 03.12.09 20:23:36, Rodolfo Lima wrote:
> John Drescher escreveu:
> > install screen
>
> Thanks for the tip but that's not my point in this whole thread (i.e.
> I'm not looking for solutions, I'm giving one).
>
> CMake does so much complicate things to make working with software
> projects a se
John Drescher escreveu:
> install screen
Thanks for the tip but that's not my point in this whole thread (i.e.
I'm not looking for solutions, I'm giving one).
CMake does so much complicate things to make working with software
projects a seamless experience across different platforms that I doubt
Michael Jackson wrote:
> True, but I can always change the "build" to something else if needed
> (like a release). 98% of the time using "Build" works just fine. I think
> there have been lots of great discussions and suggestions in this thread
> that you should be able to find something that works
2009/12/3 Rodolfo Schulz de Lima :
> Eric Noulard wrote:
>> I'm using both vi+make and Eclipse CDT (for C/C++ project using CMake).
>> In fact I was a "pure command line" guy until the noise of mouse click
>> surround me and I decided to give a try to IDE way to see the code :-)
>
> I went into the
> That's one way do deal with it, but since I use xterm I don't have tabs,
> and my monitor is a 17" 4:3, so screen space it rare. Dude... I need
> some serious tools and hardware upgrades :)
>
install screen
http://www.gnu.org/software/screen/
John
__
Eric Noulard wrote:
> I'm using both vi+make and Eclipse CDT (for C/C++ project using CMake).
> In fact I was a "pure command line" guy until the noise of mouse click
> surround me and I decided to give a try to IDE way to see the code :-)
I went into the opposite direction, from mouse to keyboard
True, but I can always change the "build" to something else if needed
(like a release). 98% of the time using "Build" works just fine. I
think there have been lots of great discussions and suggestions in
this thread that you should be able to find something that works for
you.
I envy the
Eric Noulard wrote:
> Cscope is another light and fast (compared to IDE) alternative
Thanks Eric, I'm gonna check this one out. I've heard of it but never tried.
[]s,
rod
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http
Michael Jackson wrote:
> cmake -C ${workspace_loc}/${project_name}/Build -j 16 VERBOSE=1
>
> And the executables (as setup in the Cmake files) are always built into
> Build/Bin.
This way you can only have one build tree per project. One way to extend
it is to use something like "Build_${build_typ
2009/12/3 Rodolfo Schulz de Lima :
> Michael Jackson wrote:
>> I guess those of us that use IDEs like Visual Studio, Eclipse, NetBeans,
>> Xcode, CobeBlocks, QtCreator may not see the issue you are trying to
>> solve.
>
> That's precisely it, I'm use an old-school setup, Vi + make, and my idea
> wo
2009/12/3 Jed Brown :
> On Thu, 03 Dec 2009 16:26:19 -0200, Rodolfo Schulz de Lima
> wrote:
>> About emacs/vi, they can locate the source file only if we're going
>> though an error list, as gcc spits out the path to the source files
>> involved. But if you want to load another file, you must do
On Dec 3, 2009, at 3:11 PM, Rodolfo Schulz de Lima wrote:
I'm interested to know how they manage this. But even with if you run
make with -C to change to the build directory, the executable would be
generated there. This feels awkward when you are used to in-source
builds. Inside vi I usually
Jed Brown wrote:
> I use command-find-tag "M-." and enter (a) part of the file name (not
> including the path) or (b) part of the function name, with tab
> completion, or (c) part of the struct name also with tab completion, and
> it takes me to the definition. No need to enter paths, and this wor
Andreas Pakulat wrote:
> We're using out-of-source builds (custom buildsystem) at work for about
> almost a year now. And in fact none of the developers uses an IDE, its
> emacs or vi. And none of them ever complained about that particular
> problem, I don't know exactly how they manage that (I'm u
On Thu, 03 Dec 2009 16:59:01 -0200, Rodolfo Schulz de Lima
wrote:
> Hi Jed, I know about ctags and the like, but I'm don't use them (but I
> should). But these tools cover only a part of the problem. If you want
> to go to another file and there's no useful context around the current
> file posit
Andreas Pakulat wrote:
> See my other mail, there's no way for cmake to find out which symlinks
> are dead links, except by scanning all source files on a cmake run.
> Thats a huge waste of time, especially on bigger projects with a few
> thousand files scattered over a few hundered directories.
I
On 03.12.09 16:54:08, Rodolfo Schulz de Lima wrote:
> Bill Hoffman wrote:
>
> > And, they can still have that, but I once they get used to it, I bet
> > they will like it...
>
> Sorry Bill, I think I didn't understand, you mean that they will like to
> have source code in a different directory th
On 03.12.09 16:31:06, Rodolfo Schulz de Lima wrote:
> Rodolfo Schulz de Lima wrote:
> > About emacs/vi, they can locate the source file only if we're going
> > though an error list, as gcc spits out the path to the source files
> > involved. But if you want to load another file, you must do it your
Jed Brown wrote:
> See etags/ctags (this is ancient technology). Also semantic (part of
> cedet for emacs) does semantic analysis so it can jump more
> intelligently between files (i.e. determine the type of a variable and
> jump to the appropriate definition).
Hi Jed, I know about ctags and the
Bill Hoffman wrote:
> And, they can still have that, but I once they get used to it, I bet
> they will like it...
Sorry Bill, I think I didn't understand, you mean that they will like to
have source code in a different directory than Makefile's?
> Another option might
> be a tool on top of CMake
Michael Jackson wrote:
> I guess those of us that use IDEs like Visual Studio, Eclipse, NetBeans,
> Xcode, CobeBlocks, QtCreator may not see the issue you are trying to
> solve.
That's precisely it, I'm use an old-school setup, Vi + make, and my idea
would certainly be helpful in this case.
> S
On Thu, 03 Dec 2009 16:26:19 -0200, Rodolfo Schulz de Lima
wrote:
> About emacs/vi, they can locate the source file only if we're going
> though an error list, as gcc spits out the path to the source files
> involved. But if you want to load another file, you must do it yourself,
> which can be i
Rodolfo Schulz de Lima wrote:
On Thu, Dec 03, 2009 at 12:41:59PM -0500, Bill Hoffman wrote:
Tools like emacs and other build tools can be taught how to deal with
the sources not being right there. The symlinks will likely be a pain
to maintain. What happens when a file is removed in the sour
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Dec 3, 2009, at 1:18 PM, Rodolfo Schulz de Lima wrote:
Mich
Rodolfo Schulz de Lima wrote:
> About emacs/vi, they can locate the source file only if we're going
> though an error list, as gcc spits out the path to the source files
> involved. But if you want to load another file, you must do it yourself,
> which can be irritating sometimes.
Sorry to reply t
On Thu, Dec 03, 2009 at 12:41:59PM -0500, Bill Hoffman wrote:
> Tools like emacs and other build tools can be taught how to deal with
> the sources not being right there. The symlinks will likely be a pain
> to maintain. What happens when a file is removed in the source tree?
> Who updates the
On Thu, Dec 3, 2009 at 1:18 PM, Rodolfo Schulz de Lima
wrote:
> Michael Jackson wrote:
>> I'll throw a "no" vote on that but what I would like to hear is some
>> more detail from Rodolfo explaining why he thinks he needs this? Have
>> you tried embedding the build directory inside the source direc
Michael Jackson wrote:
> I'll throw a "no" vote on that but what I would like to hear is some
> more detail from Rodolfo explaining why he thinks he needs this? Have
> you tried embedding the build directory inside the source directory?
> Some of us use this type of setup and it seems to work reall
I'll throw a "no" vote on that but what I would like to hear is some
more detail from Rodolfo explaining why he thinks he needs this? Have
you tried embedding the build directory inside the source directory?
Some of us use this type of setup and it seems to work really nicely
with IDEs, Tex
Rodolfo Lima wrote:
Hi people, I was thinking if it would be nice if cmake created symlinks
on supported platforms of source files into CMAKE_CURRENT_BINARY_DIR
when it differs from CMAKE_CURRENT_SOURCE_DIR. My only complaint against
out-of-source builds is that the sources aren't around when I d
Hi people, I was thinking if it would be nice if cmake created symlinks
on supported platforms of source files into CMAKE_CURRENT_BINARY_DIR
when it differs from CMAKE_CURRENT_SOURCE_DIR. My only complaint against
out-of-source builds is that the sources aren't around when I do make.
This feature w
39 matches
Mail list logo
