← Back to team overview

coapp-developers team mailing list archive

Re: Common library paths

 

Well, I'm not too thrilled with %pgmfiles%\CoApp directly, because that will also be used for actual applications where CoApp is the publisher.

(see Elizabeth? I knew this would come bite us...)

So option #1:

     "%CoApp_Dir%" = "%programfiles%\common files" 

or, option #2

     "%CoApp_Dir%" = "%programfiles%\common files\CoApp"

?

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

Oh, my. I do like to type, but hmmmm.  Bin/lib/include are used by a lot of MS tools (look in the SDK directory)

I'm nervous about bucking standard for no reason :D

>> Hmm, isn't a path like "C:\Program Files\doc" a bit of a weird place for documentation, since being a sub directory of Program Files kind of implies that it's a program directory.

Well, I'll agree that right off the pgm files directory is kindof funky, immutable documentation are perfectly acceptable in an app's folder somewhere.

G
	
Garrett Serack | Open Source Software Developer | Microsoft Corporation 
I don't make the software you use; I make the software you use better on Windows.


-----Original Message-----
From: Ted Bullock [mailto:tbullock@xxxxxxxxxxx] 
Sent: Thursday, April 15, 2010 2:03 PM
To: Garrett Serack
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: 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>




Follow ups

References