Re: [Anjuta-list] Project directory structure

[Malcolm Lalkaka <mlalkaka gmail com>]

On Fri, 2008-12-12 at 07:57 -0800, Mike Peterson wrote:
> On Thu, 2008-12-11 at 19:55 -0800, Malcolm Lalkaka wrote:
> > On Thu, 2008-12-11 at 21:55 +0100, Sébastien Granjoux wrote:
> > > > I reuse code a lot.
> > > > In Windows Visual Studio, I can set up a structure like this:
> > > > Source/Common - contains the common reused code
> > > > Source/Projectname - contains code for the specific project
> > > > Where "Source" is the root of all my projects.
> > > > I can't seem to find any mention in the doc for this kind of
> > > structure.
> > > > Is it possible?
> > > 
> > > I don't think it's possible.
> > > 
> > > The project file should be in the same directory than Source with
> some
> > > mandatory files with fixed names like configure.ac and so on.
> > > 
> > > I think the best way to do this, is to make a library with common
> code
> > > and use it in different project.
> > 
> > Yes, the best way to do this would be to make a library. Ideally,
> > though, a library should have some sort of logical coherence; and
> the
> > way you describe it, I'm assuming your Common directory is just bits
> and
> > piece of random but useful code.)
> > 
> > If you don't want to go through the trouble of actually building a
> > library out of Common, and you're just using this for personal
> projects,
> > another thing you can try is using symbolic links from your project
> > directories into the common directory. However, this is not a good
> > solution if you intend on distributing your project.
> > 
> > In general, referencing files from another project like you are
> > intending to do can cause problems in the long run, regardless of
> what
> > IDE you use. This is because if you change the functionality of
> classes,
> > functions, etc, under the Common directory to suit the purposes of
> the
> > project you're currently working on, it will also affect -- and
> possibly
> > break -- the other projects.
> > 
> > I absolute best solution for this kind of thing is using a source
> > control system that supports branching well, like Subversion (SVN).
> > 
> A library would be fine.
> 
> But, it would be very inconvenient to have the project that builds the
> library totally separate from the project that uses it.
> 
> Every time I need to debug, or add to the library, I would have to
> switch projects, make the edit, compile the library, switch projects
> again, compile the main project and then test the changes to the
> library. Seems like a truly awful workflow.
> 
> I would be happy with a sub-project containing the code to build the
> library within the project that uses the library.
> 
> But...I can't figure out how to do this either.

I think the symbolic link idea would solve this, wouldn't it? If your
Common directory has within it a Makefile that specifies how to build
the code within that directory, then you could create a link to the
Common directory within your other projects. When you build the other
projects, they would search the Common directory for its own Makefile,
and build it accordingly. You would have to specify Common in the
SUBDIRS variable in your top-level directory for each project that uses
the Common directory. (I haven't tried this myself, but I think it would
work.)

> When I change common files, I only fix bugs, or add non-conflicting
> functionality. (except when I screw up and break things)

(It is this exception that I my suggestion was trying to eliminate.)

> I alredy use Subversion, I will dig deeper into the doc to see if
> there is a solution hiding there.

What you want to look for is 'branching'. Basically, this allows you to
make changes to your Common code within the Common directory. Then when
you create a new project that uses Common, you 'branch' Common into that
other project, which essentially copies Common into that directory.
Later on, when you make changes to Common again, you can branch it over
to the other directory again, and it will allow you to resolve
conflicts, etc. This way, you can incrementally update your projects
with the changes you made to the Common code; and this also supports the
possibility that you've updated Common in both the Common directory and
the project-specific Common directory.

This is, of course, more work; it is intended more for large projects
than just personal projects, but it works just as well.