Directory structure and inclusion of third party libraries into projectsDirectory structure and inclusion of third party libraries into projects admin 26 September, 2009 - 17:55
I'm now using zxaf for a project, it's tried and testing code just repackaged slightly so it makes a lot of sense. What doesn't make sense though is the directory structure that the current version has. The reason being because it really doesn't lend itself to being part of a larger system, or more importantly part of a composite system.
During the initial design it looked as though it wouldn't be a problem. I thought that I'd probably use ZXAF in it's entirety for any given project, so rather than spend time trying to figure out something super scalable and elegant I went with a simple approach. The original idea was that zxaf would be integrated by exporting from svn (or extracting from tar) into the root of the project. Sounds plausible, and actually it probably would work well. However what it doesn't allow me to do is to work on zxaf and the project at the same time and have the whole lot controlled by different SVN repositories.
Inclusion of third party libraries into any software project or package or system has always been, for me at least, a dilemma, because in one way I don't want the source tree polluted by a whole raft of unrelated source code, but at the same point I want to be able to checkout the project from source control and be able to build and run with it, reliably and consistently. Although this is really more of a problem with compiled and linked projects (because there all we need are the libs), it still applies to PHP, but I suspect that the solution is different.
What the solution will finally be is still something that I'm thinking about, but it looks likely that it will be a case of putting ZXAF into a sub-directory, or maybe just moving around the areas that are changed for a project (the DB, CBF, and VIEWS), such that there is a system version of these, and a project version will be sufficient.