hi Garrett, 2010/4/15 Garrett Serack <[email protected]> > > Currently, the plan is to have something like this for common files > (bin/doc/include/lib): > > > └───Program Files [and Program Files (x86)] > > └───Common Files -- already present in Windows installations > > └───CoApp **** -- Common parent for all shared components > > ├───bin -- directory for shared tools & utilities > > ├───doc -- container directory for common > documentation > > ├───include -- container directory for library include > files > > ├───resources -- container directory resources associated > with a component > > └───lib > > > > I'm starting to think the CoApp directory is redundant, and just a waste of > space and time. > > If we dropped it, the result is: > > > └───Program Files [and Program Files (x86)] > > └───Common Files -- already present in Windows installations > > ├───bin -- directory for shared tools & utilities > > ├───doc -- container directory for common documentation > > ├───include -- container directory for library include files > > ├───resources -- container directory resources associated > with a component > > └───lib > > > > This makes it a little less cumbersome, and I highly doubt we'll see any > collision in there anyway. > > > > I like this a bit better, because in the Program Files folder, CoApp would be > considered the name of a "Publisher", not the "System". > > > > Some sample paths: > > > > % ProgramFiles%\common files\bin\grep.exe > > % ProgramFiles%\common files\include\zlib\zlib.h
I'm not sure the development files should end in a common directory. As it has been mentioned in this thread, it will not be possible to have multiple versions of a library. However I'm really not sure that the development files and the distribution package should follow the same rules. They have very different goals. Having a common (or global) include directory can also introduce problems. They cannot be solved without introducing other rules (version numbering rules for ABI/API compatibility, add extra directory like include/zlib12/). But these rules may force developers to modify their code for windows only, the #include part. That's a small change but yet another one. I would rather put them in the application directory instead and add the right path to the include/lib paths (or copy/symlink, depending on the developer needs or configuration). Btw, it is not clear if it is planed to distribute the development files with the binaries packages or as separate packages, per architecture as well. What's the plan? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
