The Nightmare of Deployment vs Compiling for Self-Use.

One thing I think developers may overlook whenever working on programs is how coding can be a much different experience than deploying it for use by the general masses. This is because he/she compiles it on his system; how will it work on other systems? Such lessons are paramount to be taken into view when working on projects that are meant to work on multiple OS's and architectures using the same code.

Particular issues:

1) When compiling for self-use, you are compiling on your architecture. This particular problem is very important when coding, as some code may not be portable to other architectures. A good example from my Wesnoth work is how I am unable to make Universal Binaries of the program simply because of the fact that the new dependencies could not be compiled for PPC. Unless if I find a solution, most probably by finding a version of the dependencies that is portable to PPC architecture, I will be forced to stick to an Intel-only binary for the 1.5 series.

2) Libraries are handled differently on different systems and compiled differently as well. One problem with the new dependencies in the 1.5 series is that I'm forced to build them differently, and is non-native to the build environment of the particular platform (even though) it's still usable. Before this, only a minimal of the libraries were made via the GNU configure-make-make install system as .dylib's. And even with the problems, the fact that they were built as static libraries made them simple to link properly. With the new libraries, I am not able to build them as static libraries, and not able to build them normally via XCode. This caused a whole ton of problems especially relating to the search paths of the libraries when launched. 

With self-compilation, these libraries are built in /usr/local/lib. However, for deployment, I am very uncomfortable with pasting libraries into the hidden folders of Mac users. However, to have these .dylibs used in other folders, I have to dabble with the install_name_tool to alter the inherent search paths of these libraries used by dyld. However, this same solution does not work with the new libraries, as the new libraries are not independent of each other. After 90 hours of frustration. I used a not so optimal but acceptable workaround. I decided to build all of the new and old GNU libraries in /Libraries/Frameworks, by making a new Wesnoth_Frameworks folder. This was followed by a manual process of picking static libraries to be deleted. I would have liked to delete some of the .dylibs as well, but because of the interdependent nature of the libraries, trying to remove the unneeded libraries would probably be a case of too much effort for too little gain.*

3) Deployment requires testing, and unfortunately, testing needs computers; optimally lots of them. This is because even with the highest scrutiny to find possible errors when other users install programs on their computers, you can always miss something. To fix them is also just a nightmare, as it may be difficult to reproduce the problems due to the different systems with different users; you will have to do a lot of history taking and depend mightily on interpreting the error reports-investigations (hehe, insert reference to medical practice here). And there is no way to know if your program works again, other than uploading a new binary (bandwidth!) and hoping that it um, finally works. Now I really regret having my old PowerBook become literally useless for general testing of programs; it's now a glorified FireWire hard drive. Thinking that what works on your computer will work on another computer is a foolish assumption for any programmer, something I learned the hard way.

4) Time should be given for "packagers" to test out these libraries with much ample time before deployment time. This is related with the above problems. Packagers should be given time to adapt to major changes in code to ensure a smooth transition, not only for self-compilation but also for deployment purposes. Adapting for self-compilation is very simple; that took me only 1 day. However, adapting for deployment has been a 10-day nightmare, and hopefully was finally solved recently.

One thing we "programmers" need to understand is that the majority of users do not compile on their own, instead depending on others to do it for them. Therefore, we must have the perception that "we need to adapt to the users' situation", and not the other way around. Therefore coding and using code should be adapted with this concept, which will indefinitely assist those involved with packaging who do the job for the end users whose systems can be very different. The packagers should also keep this view in mind; having a clean and tidy framework of files when install applications on end-users' systems ensures that there is scalability of adding new code and dependencies, among other advantages.

* There is one thing good however about this particular debacle. I was forced to completely revamp the frameworks architecture of Wesnoth, making the application much more flexible and efficient for the future as stated in my last paragraph above.