Suggestions for future releases

[Ian Roxborough]

Reiner Suikat wrote:
> 1) Import and export of build targets. I have found no way to exchange build
> target definitions between users. Since our project consists of about 20
> shared libs and 10 executables it is extremely annoying, if every user has
> to set up all targets himself. The only way to copy target definitions at
> this time appears to copy the .proj file. Unfortunately this also contains
> other things like user specific settings, which one might not want to
> overwrite.
> I think an import/exprot facility should be fairly easy to add, as writing
> project definitions to and from the .proj file is implemented anyway. All it
> needs are menu entries to import or export selected (or all) targets to an
> external file (in .proj format). Of course, this requires also some
> overwrite protection mechanism.

I've been thinking about this for a while now.  One idea I'm
kind of being to like is that of exporting/storing build target
infos in XML format.  Ideally these XML files will be able to
replace Makefiles to some extent (or Makefile.am).  SN would
be able to load up these XML files and build the projects they
represent.  But, using a tool like sn2make you could generate
regular makefiles (automated build systems, builds on headless
or remote boxes.

  $ sn2make -f mybuildtarget.sn | make all   (or whatever)

What I'd really like is a system that can not only replace
makefiles but also handle tricks and coolness of automake and
autoconf.  But without forcing developers into a GUI environment
(it'll be easier in Source-Navigator, but you can still easily
do builds, etc. from the command line).
 
> 2) Meta or super targets. With this I mean targets that define a set of
> other targets to be build. As said before, we have about 30 targets in our
> project, so rebuilding the whole thing requires 30 separate builds. With a
> super target one could do this in one step. Obviously it would be neat if
> one could define different such super targets, like build all shared libs in
> the project.

I've also thought about this to some extent.  Actually, this is
what I wanted to implement the first time around, but I called them
abstract targets.  Unfortunately, it was going to take more time
than I had to implement.
 
> 3) Projectwide  Defines/Compiler flags/Include paths. This would allow to
> change defines for the entire project easily. Such changes would be useful
> when moving the software to another machine or architecture. As a workaround
> it is of course possible to use environment variables, but that is less
> elegant.

Also, Defines/Compiler flags/Include paths/etc., on a per file basis
within a build target.
 
> 4) A version control view of the entire project. Sourcenav's version control
> support is great for single files, there is nothing missing here. But there
> is no support for the project as a whole, like a list of files that are
> modified locally or that need to be updated from the repository. This would
> be a great addition also. (Of course, one could use standalone version
> control software for that, but that means working with two different tools
> rather than one integrated tool.)

This is a "historic" problem in SN.  The version control interfaces
was designed to use many different type of version control in a kind
of plug-n-play way (add the specs to your config file a Robert's your
dad's brother, it works!).  Of course it doesn't work so great due
to the conceptual differences between different version control
systems.  This is the main reason it works for single files only...

So, for things to work at the "entire project" level, we need to
rewrite the version control UI for each version control system
we want to support.

One feature I'd like to add (post 5.0 release) is to see which
files in your project are current, changed locally and changed
in the repository.

> These are my suggestions for things I consider useful or missing in
> sourcenav. Again, I am very impressed with sourcenav! I would like to see
> other peoples opinions on these and especially of course, if any of these
> are already in the works ...

The first three items, I believe, are essential if we want to
be a serious IDE.

Anyway, I'm glad to here you like Source-Navigator and thanks
for the feedback.

Ian.