CODEWITHSUNDEEP
fortranstatic-librariesqt-creatorqmake
Odub
Odub

Reputation: 33

QMAKE_EXTRA_COMPILER execution order

Is there some way to arbitrarily assign an order on when the make is performed for the QMAKE_EXTRA_COMPILER option? It seems that declaration order seems to affect it, but it doesn't work it seems...

I have a bunch of fortran code that needs to be compiled then archived into a static library (using the ar command) to be used by a DLL I'm building. Iv been streamlining this in my .pro file to make everything happen in one go but am having a little trouble.

Heres the important stuff:

win32 {
    gfortran.commands = gfortran $${FORTRAN_FLAGS} ${QMAKE_FILE_NAME} -c -o ${QMAKE_FILE_OUT}
    gfortran.input = FORTRAN_SOURCE
    gfortran.output = ../../src/SupMods/FireNetworkDLL/${QMAKE_FILE_BASE}.o
    gfortran.CONFIG = target_predeps
    QMAKE_EXTRA_COMPILERS += gfortran
}

win32 {
    archive.commands = ar -qsc ${QMAKE_FILE_OUT} $${FORTRAN_OBJ}
    archive.input = FORTRAN_OBJ
    archive.output = ../../src/SupMods/FireNetworkDLL/libORAN.a
    archive.CONFIG = combine target_predeps
    QMAKE_EXTRA_COMPILERS += archive
}

This only works some of the time...no idea why. Also FORTRAN_SOURCE is just a list of all the fortran files (ex: fire.f95) and $${FORTRAN_OBJ} is a list of all the fortran .o files.

So is there some way I can always have the object files generated from gfortran first and follow that by the ar command? (im guessing it has something to do with dependency_type or depends...)

Also if someone has a better approach I'm all ears, first time messing with qmake really.

**Could this have something to do with the variable FORTRAN_OBJ referencing .o files that aren't actually there before the build start?

Upvotes: 1

Views: 1835

Answers (2)

Sergey Skoblikov
Sergey Skoblikov

Reputation: 5900

The order of processing of qmake extra compilers is determined by chaning of input/output variables of the compilers. For example, if the first compiler gets input files from the variable A and writes output file names to the variable B and the second compilers gets its files from the variable B, then the first compiller will be processed by the qmake before the second.

It is unclear from your sources how you populate FORTRAN_OBJ variable. Judging from the symptoms you report I suspect you fill the variable by hand. I suggest not to. Let the QMAKE_EXTRA_COMPILER to do the work automatically.

The following code should work (untested):

gfortran.commands = gfortran $${FORTRAN_FLAGS} ${QMAKE_FILE_NAME} -c -o ${QMAKE_FILE_OUT}
gfortran.input = FORTRAN_SOURCE
gfortran.output = ../../src/SupMods/FireNetworkDLL/${QMAKE_FILE_BASE}.o
gfortran.CONFIG = target_predeps

# the only change required I guess
gfortran.variable_out = FORTRAN_OBJ

QMAKE_EXTRA_COMPILERS += gfortran 

archive.commands = ar -qsc ${QMAKE_FILE_OUT} $${FORTRAN_OBJ}
archive.input = FORTRAN_OBJ
# I suggest to use $$OUT_PWD here
archive.output = ../../src/SupMods/FireNetworkDLL/libORAN.a
archive.CONFIG = combine target_predeps
QMAKE_EXTRA_COMPILERS += archive

Do not confuse processing order (generating rules to a Makefile by qmake) with execution order (execution of the rules when running make). In general the last have to be managed carefully by specifying dependencies between targets. But in this case all needed dependencies will be generated automatically thanks to the fact that by default qmake generates a dependency for each pair of the corresponding in and out files. So in this case libORAN.a will depend on all the files in FORTRAN_OBJ variable which in turn will depend on the corresponding source fortran files and the proper sequence of events is guaranteed.

If you can read Russian there is more info about QMAKE_EXTRA_COMPILERS in my blog.

Upvotes: 1

Odub
Odub

Reputation: 33

Well... ended up just adding all the object files to the final DLL instead of using a static library! Should have done that awhile ago...

Upvotes: 0

Related Questions