Program dependencies / management / architecture / book?

[daino]

I'm looking for some key works which could sum up the below. I'm going to purchase a book or a few books to help me understand these areas. Would anyone be able to suggest books or a book on this topic.

The topic is:

I want to understand more about building software, understanding how a program links to it's dependencies an why we link a program in certain ways. At this stage I'm trying to use open source software.
For example: Recently I have attempted to build some program source code though it required the Binary / Include/ and Lib directory of another program in it's makefile. When I included those three directories (i did this using a relative path), the build process worked. Given this... I still don't understand why I included those directories or how this somehow connects to the larger program.

Also. .. I don't understand why we set the Bin Path of my compiler in the system variables and how this assists the program build process or it's actual operation.

It will be tempting to pick apart this question and answer parts individually but I'm taking a longer term view. Undersanding the answers to these questions must fall under a field of study but I just don't know what that field of study is? Maybe 'project administratioN'? OR 'Understanding program communication/archtecture'. I have no doubt someone out there will have some idea what I'm talking about.

Websites are marginally useful because they have often not been edidted like books and will often contain more technical speak which clouds the main topic being explained. If anyone does have some suggestions I would be glad to hear from your.

Thanks so much.

[daino]

Was the question that difficult.. Just some keywords / tips .. Please?

[mike_2000_17]

I think your question is just too broad and too narrow at the same time. I say too broad because one could interpret it as just "I want to learn about software engineering". And I say too narrow because you make references to the specific problem of linking, using and building external libraries, which is a very practical issue (as opposed to a "computer science" issue). I personally don't really know what to make of it.

Learning to use external libraries and understanding the compiling-linking process for a given language / platform / build-system is something that you just pick up as part of the process of learning to program in those tools. There are some guidelines for sure, but by and large this is just practical know-how and common sense. My advice on that side of it would be to just look at how certain projects are setup and what their guidelines are. Many open-source projects (the good and large ones, at least) have a set of guidelines and procedures about the overall organizational issues, code reviews, unit-test policies, release schedules, version control, etc. Try reading some of them a bit, just look for them in the "developers -> guidelines" section of the project's webpage. I don't know of any books on this topic specifically. Some general C++ books will talk about some of these issues a bit, like C++ Coding Standards or Exceptional C++.

Other than that, I can't really recommend anything more. In my experience, what you often find is that practical issues, like linking different external libraries on different systems or interfaces different languages, are the kind of issues where the "academics" people who write books generally know very little about this and find it rather boring and technical, and those who know all about them (and how important they are) simply don't have time to write books because their skills and time are highly valued. I guess that makes it a bit of a "secret of the trade", so to speak. But seriously, it is probably a problem because these are really day-to-day issues that are innumerable. I often like the analogy with car mechanics (or some other vocations like it): an experienced car mechanic probably has a gizillion tricks about what to do in day-to-day situations (e.g., a rusty bolt that is stuck, or a hard-to-reach thingy), to intuition about what is wrong with a specific car (by sound alone), or just knowing what problems are common with what specific car models, and so on. You cannot get the mechanic to sit down and start writing down everything he knows and use that as a teaching tool, all you can do is teach the basics and the necessary to get the mechanics students to be functional in their job, but all the practical tricks and know-how, they learn from experience, and through specific questions directed at their mentor(s). And that's how I learn just about every practical trick that I know of, and that's how I slowly migrated towards certain "preferred" design patterns, platforms, libraries and build tools.

When it comes to external libraries, the one pattern you must know about is PImpl (often called "Cheshire Cat" or "Compilation Firewall", or less often, "Guarding Class", "Handle Class", or "Bridge Pattern"), and the almighty "forward-declaration" feature of C++. When it comes to just building libraries and your own code, just read instructions / tutorials carefully, ask questions if necessary, and make sure that you use build tools that are as automated as possible (i.e., a one-action tool that just configures itself on its host system and builds the entire code without human intervention necessary (unless external dependencies are not installed, which the build system should automatically detect and report), tools that fit this description include cmake, bjam, qmake, and a few others). And finally, when it comes to being familiar with different systems / platforms, the good news is that there are really only 2 platforms, from a native-code programming point of view: Windows (for MS Windows products) and Unix (for everything else). And Unix / Linux is far smoother and more predictable to deal with than Windows, so prefer that if you have a choice.

For the broader issues, search for "Software Engineering", as well as "Software Project Management". And then, you have all the gizillion design patterns out there.

[daino]

Thanks very much for the detailed post mike.. I'll certainly look into that..

Cheers