coapp-developers team mailing list archive

[<alternate_rg@xxxxxx>]

I  think like Ted Bullok, that the CoApp directory is ok, because CoApp is
the publisher and identified in the directory structure by itself.

-----Ursprüngliche Nachricht-----
Von: coapp-developers-bounces+alternate_rg=web.de@xxxxxxxxxxxxxxxxxxx
[mailto:coapp-developers-bounces+alternate_rg=web.de@xxxxxxxxxxxxxxxxxxx] Im
Auftrag von Ted Bullock
Gesendet: Thursday, April 15, 2010 11:03 PM
An: Garrett Serack
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx
Betreff: Re: [Coapp-developers] Common library paths

2010/4/15 Garrett Serack <garretts@xxxxxxxxxxxxx>
> Hmm. This leads to wondering if we really need “common files” in the
middle. I’ve never seen bin/lib/doc/include in program files…
>
> Comments?

A couple things.

I think the CoApp directory is ok since it creates an actual location
for all things coapp.

Common files is ok because we want it to be shared....

I wonder about calling it bin, lib, doc....  why not something
non-unixy and more english like executables, libraries, documentation.

Also there is another thing; I think the include directory should be
versioned for each shared dependency.  There are situations where
developers do not want to link to the latest version and it shouldn't
be overwritten by updating the package.  Most of the time this won't
be the case, but it is not a lot of extra work to support the
alternative.

That is to say:

%CoApp_Dir%\include\zlib\  <- Junction to zlib-1.2.3
%CoApp_Dir%\include\zlib-1.2.3\zlib.h
%CoApp_Dir%\include\zlib-1.2.2\zlib.h

--
Ted Bullock <tbullock@xxxxxxxxxxx>

_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp