![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
solipsistnationDear programmers, academics, professors, researchers, and so on:
During the process of developing your incredibly complex software, be it a visualization package, a set of libraries for solid-body physics simulations, a piece of computational software designed to be run on a massively parallel cluster, or whatever, you may find yourself thinking, "You know what I need? I need a way to make sure this can build on lots of different systems, and not just my workstation."
At this point, I'd like to congratulate you. By even acknowledging that there may be other computers in the world that are not configured in an identical fashion to the hacked-together linux box on your desk, you have surpassed the state of technical awareness of (in my experience supporting researchers on a variety of platforms, compiling and installing for them a variety of software packages) almost 50% of your colleagues. Well done! Don't take this lightly-- a piece of software with ANY automatic configuration system (or even a documented hand-configuration system) is a great first step. The systems administrators of your collaborators at other institutions thank you!
It is, unfortunately, only the first step.
The next step is to consider standards. Standards exist for a reason.
You may, upon deciding to release your creation to the world at large, feel a need to make sure it can compile on a variety of platforms with a minimum of hand-tweaking. There are many ways to go about this process. Some of them are standard and well-supported, and exist and function on almost all posix-compliant (and many non-posix-compliant) platforms. (POSIX is a standard. Standards are good. Remember this.) Some of them are nichey and don't work well at all. Some of them are, essentially, crap.
You may decide to write your own auto-configure system using a bunch of shell (or perl, python, ruby, or for the love of all that's holy, PHP) scripts of your own devising. Turn back now; this way madness lies. Mines. Seriously, I will come to your house and poke you with a stick.
You may decide to use some other configuration or build system, or some needlessly-complex wrapper of some sort. This could include something like ccmake, jam, cook, nmake, and so on. Don't do it. Don't believe the hype; they're more trouble than they're worth.
You may decide to design your own configuration and/or build system, and require that users install that first, before even attempting to compile your software. This is a terrible offense against man and nature, and your punishment will be swift, harsh, and final.
Please, please, for the sake of all that is good in the world, just use gnu autoconf/automake, and require nothing more than gnu make. They're everywhere. Everyone has them, or can easily acquire well-supported versions of these software packages that will run in a solid, predictable fashion on every platform out there.
In short, I do not want to have to in
I thank you; the sysadmins of your collaborators thank you. Science will be better as a result, I promise. (Partially because no scientist/programmers will have grievous head wounds and fewer resulting concussions.)
Huggles,
a university systems administrator.
PS: (Kitware, I'm talking to YOU in particular. When your lawns turn brown it's because I am peeing there. cmake. What were you thinking?)
During the process of developing your incredibly complex software, be it a visualization package, a set of libraries for solid-body physics simulations, a piece of computational software designed to be run on a massively parallel cluster, or whatever, you may find yourself thinking, "You know what I need? I need a way to make sure this can build on lots of different systems, and not just my workstation."
At this point, I'd like to congratulate you. By even acknowledging that there may be other computers in the world that are not configured in an identical fashion to the hacked-together linux box on your desk, you have surpassed the state of technical awareness of (in my experience supporting researchers on a variety of platforms, compiling and installing for them a variety of software packages) almost 50% of your colleagues. Well done! Don't take this lightly-- a piece of software with ANY automatic configuration system (or even a documented hand-configuration system) is a great first step. The systems administrators of your collaborators at other institutions thank you!
It is, unfortunately, only the first step.
The next step is to consider standards. Standards exist for a reason.
You may, upon deciding to release your creation to the world at large, feel a need to make sure it can compile on a variety of platforms with a minimum of hand-tweaking. There are many ways to go about this process. Some of them are standard and well-supported, and exist and function on almost all posix-compliant (and many non-posix-compliant) platforms. (POSIX is a standard. Standards are good. Remember this.) Some of them are nichey and don't work well at all. Some of them are, essentially, crap.
You may decide to write your own auto-configure system using a bunch of shell (or perl, python, ruby, or for the love of all that's holy, PHP) scripts of your own devising. Turn back now; this way madness lies. Mines. Seriously, I will come to your house and poke you with a stick.
You may decide to use some other configuration or build system, or some needlessly-complex wrapper of some sort. This could include something like ccmake, jam, cook, nmake, and so on. Don't do it. Don't believe the hype; they're more trouble than they're worth.
You may decide to design your own configuration and/or build system, and require that users install that first, before even attempting to compile your software. This is a terrible offense against man and nature, and your punishment will be swift, harsh, and final.
Please, please, for the sake of all that is good in the world, just use gnu autoconf/automake, and require nothing more than gnu make. They're everywhere. Everyone has them, or can easily acquire well-supported versions of these software packages that will run in a solid, predictable fashion on every platform out there.
In short, I do not want to have to in
I thank you; the sysadmins of your collaborators thank you. Science will be better as a result, I promise. (Partially because no scientist/programmers will have grievous head wounds and fewer resulting concussions.)
Huggles,
a university systems administrator.
PS: (Kitware, I'm talking to YOU in particular. When your lawns turn brown it's because I am peeing there. cmake. What were you thinking?)