coapp-developers team mailing list archive

[Pierre Joye <pierre.php@xxxxxxxxx>]

hi Garrett,

2010/4/15 Garrett Serack <garretts@xxxxxxxxxxxxx>
>
> 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