I'd like to use emacs to work on my project that is built using CMake, while this generally works fine, I'd like to implement better project management commands. Is there a simple way to generate some sort of file that acts as a listing of the project files.
It seems that the best way may just be some set of CMake macros that do a custom write to a file, is there perhaps any better solutions?
I have no direct experience with CMake. But there are a couple of approaches to solving this.
The canonical way is to generate a TAGS table as a part of your buid process. You will get symbol completion/navigation on top of easy access to file-list. And ctags is hyper fast. I'll leave you to google how to do that specifically, hint: wiki.
Alternatively, you can get a Emacs project management package like EDE, eproject, mk-project that defines the concept of a project. See wiki.
You can look onto CEDET mailing list - CMake support was discussed not so long time ago, and at least one person is actively working on CMake support in EDE (CEDET's project management)
Related
Recently I've begun taking advantage of the features offered by using robust IDEs, particularly the debugger and autocomplete found in Eclipse Juno and Visual Studio 2012.
However, many of my projects deal with lots of local files; for game projects I have custom content files, for data mining I have lots of data files that need to be referenced from a set of Python scripts, etc.
My issue is that storing these files within the project structure of the IDE seems hacky somehow (also, the IDEs tend to require a single entry point, which isn't so cool for working with data via a suite of scripts). The only other option I've found, using absolute paths relative to the drive, results in less-than-generalizable code.
My question: is there a good, clean method for referencing local data files (text files, XML, images, etc.) while still taking advantage of the features of a heavyweight IDE?
It seems there are ways such as "debug in directory" and "local reference folder" systems, but I'm wondering if there's some general way people deal with this.
Thank you for any information or suggestion!
As for me, I'm always just either:
storing files in the project dir, and using a versioning system (svn, git) exclude those and only include the directories they're in
symlink the files, or whole directories, depending on the structure, into the project ; if you use relative symlinks instead of absolute ones, it makes it pretty easy for multiple people to have different files/content while still working on the same project over one repository. As it seems you're using windows (afaik visual-studio is windows only?), I think that newer windows versions should support symlinks as well, up from vista as far as I remember.
Edit: quick google search led me to: http://en.wikipedia.org/wiki/NTFS_symbolic_link
I would like to ask if any of you have any experience {and,or} could point me to a project management extension for Emacs that works well with {Scala,Ensime,SBT}. It would also be amazing if it didn't require too much hacking. I did some scheme in the past but I have little experience with the Emacs platform.
Basically, by project management I mean mainly the ability to 'tie files into project' and then search among them (and only among them).
Thanks for taking the time to read this and answer!
I really hate that you can't setup projects out of the box, though.
Just set up the project with sbt or maven and import it with ensime.
Essentially, what i would want is to be able to flex-find files in the project
"flex-find" is not English, so I don't really know what you mean. But what is wrong with find (the command line tool)?
With ensime you can load your project and then search for a type or method by name. The key sequence is C-c C-v v. This allows you to, for example, jump directly to a class definition.
The package projectile has a bunch of generic project-level features, such as running commands in the project root folder, grepping, creating TAGS files etc.
I'm a relatively new user of it, so I can't say exactly how big a difference it makes, but it seems like a worthwhile addition to your tool belt.
I am using bazaar as a version control system for my research. I have many latex documents. I want to display the version number in all the .dvi files under bazaar.
The easiest way to accomplish this will be to use make or a similar build manager to generate your .dvi files.
Your Makefile should include a new target called version-number:
version-number:
bzr revno > VERSION.tex
and your .dvi targets should depend on version-number:
my-project.dvi: my-project.tex [OTHER STUFF] version-number
In your .tex files, at an appropriate place (in the header/footer, title block, PDF metainfo, etc) you would include the version number stored in VERSION.tex:
\input{VERSION}
When you set this up you should bzr ignore VERSION.tex so that it won't store its own version number, of course.
This is all based on a similar technique used for git in the Common Lisp Quick Reference project.
Maybe the bazaar keywords plugin can help you.
I have used the latex VC package successfully with Bazaar. It works using an external script that is called during compilation by \write18. This may seem overkill but it provides a lot of functionality and works well.
Following is a question that is posted on http://dev.eclipse.org in April 2003. The original question is:
Hi all,
in eclipse i have created several java
projects representing different
modules for one web application. i'd
like to configure one output folder
for all of these projects. Any time i
build a subproject the content of the
output folder is deleted, so i loose
the classes of all other subprojects.
I think there must be a switch or
something like that to tell eclipse
not to clear the content of the output
folder when it builds a project - but
i just can't find it.
Thanks for your help!
Alex
I am trying to see if I could get a definitve answer for this question. I have tried to find out to see if this question has already been addressed and I was not able to find any except for the following answer:
Window-->Preferences-->Java-->Compiler-->Build Path
The above answer did not help me much.
Hmm... I think this approach will bring more trouble than it's worth. Sure it's a priori a quick and dirty fix to integrating your projects together but you are only pushing the problem forward. It is good practice to keep your modules as isolated as possible from each-other, trying to merge the compiled code in a single location is working against the way the IDE was designed and will only bring trouble.
I would recommend that you look into maven to build and package your modules. Then referencing them is just a matter of adding a declaration in the project that requires it and you are integrated. Of course you will need to learn it but it provides a good base of conventions that when followed yield almost effortless integration. Plus reusing some modules in another project becomes trivial so you gain in all fronts.
To answer the other question in the thread when they wish to make a tree of related projects it is possible though somewhat clumsy. Eclipse will always present projects as a flat list, however the folders can be arranged in a tree nonetheless. Just specify a custom location when creating a project or import the project from the sub-folder. Again here Maven can help a lot with it's concept of modules.
As eugener mentioned in his comment, there are plugins for maven that will make most of these tasks trivial. You may find all you are looking for just by exploring the gui, this said, reading the maven literature will give you good insight on how it works and what it can do for you.
Putting development tools (compilers, IDEs, editors, ...) and runtime environments (jre, .net framework, interpreters, ...) under the version control has a couple of nice reasons. First, you can easily compile/run your program just by checking out your repository. You don't have to have anything else. Second, the triple is surely version compatible as you once tested it. However, it has its own drawbacks. The main one is the big volume of large binary files that must be put under version control system. That may cause the VCS slower and the backup process harder. What's your idea?
Tools and dependencies actually used to compile and build the project, absolutely - it is very useful if you ever have to debug an issue or develop a fix for an older version and you've moved on to newer versions that aren't quite compatible with the old ones.
IDE's & editors no - ideally you're project should be buildable from a script so these would not be necessary. The generated output should still be the same regardless of what you used to edit the source.
I include a text (and thus easily diff-able) file in every project root called "How-to-get-this-project-running" that includes any and all things necessary, including the correct .net version and service packs.
Also for proprietry IDE's (e.g. Visual Studio), there can be licensing issues as this makes it difficult to manage who is using which pieces of software.
Edit:
We also used to store batch files that automatically checked out the source code automatically (and all dependencies) in source control. Developers just check out the "Setup" folder and run the batch scripts, instead of having to search the repository for appropriate bits and pieces.
What I find is very nice and common (in .Net projects I have experience with anyway) is including any "non-default install" dependencies in a lib or dependencies folder with source control. The runtime is provided by the GAC and kind of assumed.
First, you can easily compile/run your program just by checking out your repository.
Not true: it often isn't enough to just get/copy/check out a tool, instead the tool must also be installed on the workstation.
Personally I've seen libraries and 3rd-party components in the source version control system, but not the tools.
I keep all dependencies in a folder under source control named "3rdParty". I agree that this is very convinient and you can just pull down the source and get going. This really shouldnt affect the performance of the source control.
The only real draw back is that the initial size to pull down can be fairly large. In my situation anyone who pulls downt he code usually will run it also, so it is ok. But if you expect many people to pull down the source just to read then this can be annoying.
I've seen this done in more than one place where I worked. In all cases, I've found it to be pretty convenient.