MYSTRAN Forum

Full Version: Linux Compiling
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
What are the options for compiling on Linux Ubuntu? Is there a CMake file for linux?

The github instructions are not very enlightening:
"If compiling for Linux:

1. Rename the other 3 files in this directory to have a ".f90" extension instead of a ".tmp" extension.
2. Delete the files in the "1_Windows" directory."
We have do not have anything official for Linux and I do not know if anyone has tried that approach yet. The instructions on GitHub are just for how to set up the source code for readiness to compile. It is not a compile process. Have you seen this thread thread about compiling? While these options are primarily for Windows, would they be useful for Linux? Code::Blocks can be used on Linux and there is a CMake approach (the Visual Studio option is not relevant). One challenge might be that we are using a special Code::Blocks version for now, which has been compiled for Windows. But the standard Code::Blocks version might work since it accepts a longer command line string. That is TBD.

https://www.mystran.com/forums/showthread.php?tid=2
I have tried compiling under Linux using the provided CMake files. I got the CMakeLists.txt, then told CMake to generate the Makefile... basically, the same commands as the .bat file, save for replacing "gFortran" with "gfortran", since Linux file names are case sensitive. However, upon calling make, one of the source files fails to compile due to referencing an unknown module.

Here's the full terminal output: https://pastebin.com/0WMGAAeE.

I'm using git master's latest (commit f22e1b2 as of this writing), the unmodified CMakeLists.txt from the link, CMake 3.17.3, GNU Make 4.3, and gfortran (gcc) 10.1.0 under x86_64 Arch Linux.

Maybe someone with a better understanding of the source code and internals could be of help? Assuming the current master branch is OK, that could only be an out-of-date CMakeLists.txt, but I don't know enough about CMake or the MYSTRAN source code to fix this. I'm hell-bent on getting this to compile on Linux though!

Any ideas?
Hi Borges. The CMake file you have must be incorrect since BANDIT_MODULE must be compiled before that point where your compilation stopped. I will make a list of a file order that should work for you. I have compiled the program for many years using batch files and perl scripts. From that I can make the list you can use. It may take a day or so and might require a couple of iterations to get it working but we will get there, I'm sure
Interesting... never thought it was about order.

I'll fiddle with the order settings within the CMakeLists.txt file while I'm at it.
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.
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.
(08-12-2020, 03:35 PM)drbillc Wrote: [ -> ]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).


(08-12-2020, 07:43 PM)Admin Wrote: [ -> ]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).
Some responses:

- I agree that Code:Blocks is not an ideal solution in various ways. It has a GUI, which can be nice, but it also has some quirks. The major objective was to get away from the Lahey compiler that Bill was using and the Code::Blocks approach is at least one option. We had tried some other approaches, but we were not able to finish them. Also, if files are added/removed from the source code, you just have to adjust them in C::B. That is a quick change (most of the time consuming aspect is the setup and internal options which remain).

- On that note, a few people tried to use Makefiles, but were not successful (hence C::B is the default approach today). But if you able to come up with a Makefile, then that is exactly what we need, so thanks!

- Regaring Cean's attempt (https://www.mystran.com/forums/showthread.php?tid=38), there was a time when we removed BANDIT was removed from the code (since it needed to be touched up). Later, Bill reworked it we added it back into the source code. So it may be that it was not part of the code at all when Cean worked on it.

- In any case, we can use all the help/options we can get. So if you are successful, we can add the processes and/or adjust the source code as necessary. Ideally, we would like a non C::B option for Windows as well, but something for Linux would be great. We haven't had any developers interested on the Linux side yet, but it seems are few more are interested now. Also, we are lacking a Linux 11.0 build, so it would be good to add that for end users.
(08-13-2020, 02:15 PM)Admin Wrote: [ -> ]Some responses:

- I agree that Code:Blocks is not an ideal solution in various ways. It has a GUI, which can be nice, but it also has some quirks. The major objective was to get away from the Lahey compiler that Bill was using and the Code::Blocks approach is at least one option. We had tried some other approaches, but we were not able to finish them. Also, if files are added/removed from the source code, you just have to adjust them in C::B. That is a quick change (most of the time consuming aspect is the setup and internal options which remain).

- On that note, a few people tried to use Makefiles, but were not successful (hence C::B is the default approach today). But if you able to come up with a Makefile, then that is exactly what we need, so thanks!

- Regaring Cean's attempt (https://www.mystran.com/forums/showthread.php?tid=38), there was a time when we removed BANDIT was removed from the code (since it needed to be touched up). Later, Bill reworked it we added it back into the source code. So it may be that it was not part of the code at all when Cean worked on it.

- In any case, we can use all the help/options we can get. So if you are successful, we can add the processes and/or adjust the source code as necessary. Ideally, we would like a non C::B option for Windows as well, but something for Linux would be great. We haven't had any developers interested on the Linux side yet, but it seems are few more are interested now. Also, we are lacking a Linux 11.0 build, so it would be good to add that for end users.

Some good news then: I think I have produced a working CMakeLists.txt from Cean's. It generates a valid Makefile that can compile MYSTRAN all the way, just a "cmake && make" and you're all set. The resulting binary works; I ran some models, results are produced as expected, and albeit I don't have my Windows machine on me right now to visually check the results, they seem to be correct.

There are lots of warnings, though; probably because this source tree wasn't originally meant to be compiled with gfortran, but this is very promising. The only thing I'm not confident in are my changes to the READ_CL subroutine's GETARG calls -- I have very little experience with Fortran --, but that was the only way that file could ever compile under gfortran, since GETARG is a compiler extension added for F77 compatibility, and takes only two arguments. Silently suppressing the STATUS value is hacky at best, and a better solution would be checking iargc() to set STATUS before even calling GETARG. Personally, I'd get rid of compat/extension calls entirely and replace them with F95-introduced alternatives in the long run.

Anyway, I'll touch up the listfile, add a proper .gitignore, put together a fork, sort my changes into a commit or two, and link a pull request here later today.

If you like what you see, we can get a Linux x86_64 automated build going on very soon!
Pages: 1 2