Linux Compiling

[borges]

Hi Borges,
I have a first cut at the list for the order in which to compile MYSTRAN. One of the reasons an order is required is that the code contains modules that are used in subroutines and they have to be compiled before some of the code. If you send me an email at the address in the Contact tab on the MYSTRAN.com web site I will respond with an Excel file that has the order. If you can't deal with Excel let me know and I'll send a plain text copy. Since I don't use that list when I compile it may take us an iteration or 2 to get this working.

Email sent. That file will sure be of help (see last paragraph).

borges, do you know if Code::Blocks might work? The following link contains the instructions for Windows. There is a major difference though. You would just download C::B from their site (http://www.codeblocks.org/downloads/26) (do not use the specific version we have for Windows, which contains a patch for long command line lengths). In other words, you should be able to go to page 4 of the following document after you download C::B for Linux. I am not sure if you will run into a command line length issue though. Linux is more generous than Windows, so it may or may not work (but I recommend putting the source code in a directory with a very small path to maximize the chance that it will work).

https://www.mystran.com/compile/MYSTRAN_...ks_5.2.pdf

P.S. Also, read the text file in the "2_Linux" directory of the source code. You need to make some minor modifications to set it up for Linux.

So, about Code::Blocks... I'm not a big fan of depending on a GUI program to bootstrap the compilation process. I'll consider it a "if all else fails" sort of option.


The thing is, Code::Blocks doesn't do magic: all it does is generate a CMakeLists.txt file, which is then used to generate a Makefile, and said Makefile does all the work. A good CMakeLists.txt file is all you need, so one could argue "use Code::Blocks to generate good CMake files and use those for compiling wherever".


That sounds doable -- I might even give it a shot -- but I don't like the sound of it for one simple reason: it's not a good long-term solution. Since Code::Blocks uses internal "project" information (namely, the .cbproj file) to generate the CMake files, it needn't care for their structure. Put simply, they're made for Code::Blocks to read, write and use. What this means is, should any changes occur in the source code structure (e.g. a source code file added, removed or renamed), the CMakeLists.txt file can no longer produce a working Makefile, meaning someone will have to boot up Code::Blocks and repeat the process all over again.


In my opinion, the compilation info/scripts should be a part of the project files. See, if you download project that is supposed to be built with CMake, it'll have a CMakeLists.txt somewhere in its source tree. Same if you download a project that uses the GNU Build System: somewhere there will be a configure script and a Makefile.in file. Adacore GPS projects will have a .gpr file. Simpler projects will sometimes just have a hand-written Makefile. It's very rare for a project not to have any build script/file.



Aaand from that tangent arises a good long-term solution: have a good, likely handwritten build file/script in the source tree, such as a CMakeLists.txt, a Makefile, whatever works. Not only will it make the build process more consistent across updates, it'll remove the need for user intervention (such as the 1_Windows or 2_Linux folder removal and file renaming) entirely. In fact, that's what I'm currently working on. Since I'm not very familiar with CMake and have some experience with compiling NASTRAN-95 (more than I find to be healthy) for both Windows and Linux, it's gonna be a Makefile for now. I'll likely need to have a look at the aforementioned "compile order" spreadsheet to get it working though.

---

Also, quick note: I was experimenting with the CMakeLists.txt, and noticed it didn't compile any part of BANDIT at all, so I did some fiddling... namely, told it to compile BANDIT. I found a couple issues with the READ_CL sub too: GETARG is a compiler extension, and under gfortran, it takes takes two arguments, so you'd have to check iargc instead of getting a STATUS.

After fixing those two things (getting rid of STATUS in READ_CL and telling CMake to compile and link against BANDIT), I actually got it to compile under Linux!

All one would need to compile now (under any platform) is running "cmake . && make" in the Source folder. (In multicore systems e.g. quadcore, make -j 4 dramatically increases speed, so use that as well).