I'm fairly sure Xcode still has Build Rules. Here's a page on it at Apple, but it's not useful in any practical sense:
https://developer.apple.com/library...ject_editor/Articles/Adding a Build Rule.html
Searching for
xcode build rule finds other articles, but their dates suggest they haven't been revised in a while. Example from 2012:
http://www.cocoanetics.com/2012/02/xcode-build-rules/
and one from 2013:
http://www.objc.io/issue-6/build-process.html
If recent Xcode versions still have Build Rules at all, they should work pretty much the same as they did in the past.
The gist of it is that Xcode acts sort of like 'make' when it comes to building. It has a number of "things to build" (targets). It also has a list of "things needed by the fully built target". For make, that list is explicit (the OBJECTS files); in Xcode it's implicit (based on a file being used by the target). Both 'make' and Xcode also have sets of rules for transforming files, for example, to transform a .c file into a .o file, the rule consists of the input suffix (.c), the output suffix (.o), and a command that produces the output from the input (cc -o OUT.o IN.c).
Both 'make' and Xcode let you add rules. I know older versions of Xcode let you do this, because I use that feature often. I don't know for sure if newer Xcode versions have this, nor do I know where one would look to add or modify the build rules. That's where finding a recent article will be useful. The above article from 2012 may give enough clues to find it, in whatever Xcode version the OP is using.
Once the "Where do I put a build rule?" question is answered, the next question is what to put into the rule. The first thing is going to be the suffixes: .f or .for for the input, and .o for the output. Next is the transformation action (command). That's usually going to be a command-line, such as:
Code:
gfortran "$INPUT_FILE_REFERENCE_HERE" -o "$OBJECT_FILE_REFERENCE_HERE"
Once a rule is defined, then when Xcode sees a .for file (or .f, or whatever) it will know to run the command in the rule, using the specific files involved.
There will always be some tricky stuff, like ensuring the output file gets put into the proper place (the Build folder). Consult the Xcode reference on Build Rules, Build Variables, and don't be afraid to look at a verbose build log, or the log produced by running 'make'. Lots of details can be found there.
The last step will be linking all the .o files into a complete executable. For that, a custom Run Script build step might be useful. It can contain something that looks similar to however the executable is built without Xcode. That is, if 'make' or a shell script runs the 'ld' command with a bunch of options, then do the same thing in the Xcode build step.
I've used past Xcode versions with custom build rules that:
- Compile & download Atmel AVR code for Arduino boards.
- Run an 8051-family assembler for a custom-designed board.
- Process HTML, CSS, & JavaScript for embedding into a ConnectOne wifi module.
These were all done for various different projects, and when I moved to the next project I'd generally start with the project that most resembled my new one, and then tweak build rules, linker phases, etc. None of this required an Xcode plugin, just Build Rules and Run Script build phases.
I'm still using older Xcode versions, so I can't say if recent versions still have Build Rules, Build Phases, and so on. If they do, then the above is a general guide. You'll still have to navigate Xcode to access and define build rules, add phases, and so on. You'll also need to know about Build Variables, which hold important things like the name of the file to compile, the Build folder for objects, and the options set by the user.
The last point I'll mention is this: "Start Simple". That is, start with a single-file Fortran program, that needs only the Fortran intrinsic functions and libraries. It will be much simpler to develop build rules, linker phases, etc. on a trivial program than on the final multi-file one.
Once the single-file program is working, add one file to the project. Make sure it still builds and runs correctly. At that point you can move to more complex test cases, or even the actual program you wanted. The key is to start simple and work up, rather than jumping directly into the deep end.
Worst case there's always 'make'. It may be primitive and repetitive, but it does work, and there are tutorials for it.
