Re: [Anjuta-list] Project directory structure

[Mike Peterson <mikep loudroundrecords com>]

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 understand the concern about changes to common files breaking older
projects, but I have been using this scheme in Visual Studio for over 10
years, and I rarely break things.
When I change common files, I only fix bugs, or add non-conflicting
functionality. (except when I screw up and break things)

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