How to name makefile in .pro file?

[DigiDrag]

Hi

I want to cross-compile a QT project.
And I am accessing the same project folder from different OS over the network.
And this leads to a problem:
All OS are using the same makefile name 'Makefile' and this leads to problems as QT does not re-create that file on the next OS.


Does anyone know how I can specify the makefile name in the .pro file?


I want to get something like this:
mac {
make_name = Makefile_Mac
} else:unix {
make_name = Makefile_Linux
} else {
make_name = Makefile_Win
}


thanks,
dd

[mcosta]

You can set the QMAKE_MAKEFILE variable!

mac {
QMAKE_MAKEFILE = Makefile_Mac
} else:unix {
QMAKE_MAKEFILE = Makefile_Linux
} else {
QMAKE_MAKEFILE = Makefile_Win
}

mac {
QMAKE_MAKEFILE = Makefile_Mac
} else:unix {
QMAKE_MAKEFILE = Makefile_Linux
} else {
QMAKE_MAKEFILE = Makefile_Win
}

To copy to clipboard, switch view to plain text mode 

[DigiDrag]

Hi

Thanks so far, got half the solution.

It does not seem to work with the QT Creator.
It now generates the makefile with a different name, but QT Creator does not start make with the new filename...

And I cannot define make arguments in the .pro file.
And the arguments in the QtCreator file are not platform-dependants.
And I am also not able to use and system-wide variable as make argument in QtCreator as it is not resolved...

[wysota]

Wouldn't it be easier to do shadow builds so that makefiles for each platform end up in different directories? Your problem would vanish instantly.

[DigiDrag]

Wouldn't it be easier to do shadow builds so that makefiles for each platform end up in different directories? Your problem would vanish instantly.

I found the option to enable and change a shadow build directory in the QT Creator.
But again, this setting is the same on all platforms...

[ChrisW67]

Does something like this fly for you?

macx { 
  MOC_DIR = build_mac
  OBJECTS_DIR = build_mac
  RCC_DIR = build_mac
  UI_DIR = build_mac
} else:win32 { 
  MOC_DIR = build_win32
  OBJECTS_DIR = build_win32
  RCC_DIR = build_win32
  UI_DIR = build_win32
} else {
  MOC_DIR = build_unix
  OBJECTS_DIR = build_unix
  RCC_DIR = build_unix
  UI_DIR = build_unix
}

macx { 
  MOC_DIR = build_mac
  OBJECTS_DIR = build_mac
  RCC_DIR = build_mac
  UI_DIR = build_mac
} else:win32 { 
  MOC_DIR = build_win32
  OBJECTS_DIR = build_win32
  RCC_DIR = build_win32
  UI_DIR = build_win32
} else {
  MOC_DIR = build_unix
  OBJECTS_DIR = build_unix
  RCC_DIR = build_unix
  UI_DIR = build_unix
}

To copy to clipboard, switch view to plain text mode 

You leave Qt Creator's shadow build feature off in this case.

[DigiDrag]

Hi

Thanks, but I am already using these parameters.
This works fine, it is just the makefile itself.

If I compile on Mac and then try to compile on Linux, then the makefile is not re-generated.
And therefore the MOC_DIR, OBJECTS_DIR, RCC_DIR, UI_DIR are not updated in the makefile...

[wysota]

Honestly I would just rerun qmake and forget about the problem.

[miwarre]

I have the same problem.

Honestly I would just rerun qmake and forget about the problem.

This would be sub-optimal; and what is the point of an automated make, if you have to run some (quite important) step manually?

Anyway, I tried the above solution and it is not an out-of-source (or shadow) build: all makefile's are in the same directory of each .pro as well as the debug and release sub-dirs with the executable(s).

So, I would re-formulate the question in this way:

Is there a way to have a REAL out-of-source AND multi-platform build by using .pro settings and without using the Shadow build setting of Qt Creator (which IS out-of-source but IS NOT multi-platform) ?

The best of any possible world would be to be able to launch the build from within Qt Creator itself, with just a click on the the 'hammer' button...

Thanks!!

M.

[wysota]

This would be sub-optimal; and what is the point of an automated make, if you have to run some (quite important) step manually?

What is the point of placing intermediate files (such as the Makefile) on a shared remote disk?

Is there a way to have a REAL out-of-source AND multi-platform build by using .pro settings and without using the Shadow build setting of Qt Creator

I don't really see a point of doing that in a single directory. But if you insist... Use the -o parameter of qmake and -f parameter of make.

[miwarre]

What is the point of placing intermediate files (such as the Makefile) on a shared remote disk?
...
I don't really see a point of doing that in a single directory. But if you insist... Use the -o parameter of qmake and -f parameter of make.

Hmmm, am I missing something? It is not me, it is Qt Creator which insists on creating makefile's in the same folder as the .pro's files.

I tried any combination of .pro settings I could think of and none seems to work:

Using either MAKEFILE = Makefile_<platform> or QMAKE_MAKEFILE = Makefile_<platform> or both, 6 Makefile's are created in the .pro dir: Makefile, Makefile.Debug, Makefile.Release, Makefile_<platform>, Makefile_<platform>.Debug, Makefile_platform>.Release.

Using something in the line of [QMAKE_]MAKEFILE = ../build_<platform>/Makefile simply does not work: at some point some of the programmes involved complains about there being no target or no makefile.

But if you insist... Use the -o parameter of qmake and -f parameter of make.

Which parameters cannot be places in a .pro file, I assume. They have to be placed in Qt Creator project configuration dialogues (Ctrl-4) whose settings are common across all platforms and we are at square one again...

Let me re-state my goals once again:

Thesis: I have one src dir with all the sources and I access this dir from BOTH Windows and Linux Qt;
Goal 1) I would like no leftover step from the build on one platform to be mistaken for an already performed step by the other platform
Goal 2) I would like no intermediate file to pollute the src dir
Goal 3) I would like to work from inside an IDE, Qt Creator being the obvious choice in this case.

It seems to me a reasonable pretense, isn't it?

Yours very confused,
M.

[wysota]

Hmmm, am I missing something? It is not me, it is Qt Creator which insists on creating makefile's in the same folder as the .pro's files.

If you are using a hammer to connect two planks with nails and then you decide to change the nails to screws, why do you keep using the hammer instead of a screwdriver?

If Qt Creator doesn't work for you then don't use it. Use proper tools for the job.

Thesis: I have one src dir with all the sources and I access this dir from BOTH Windows and Linux Qt;

A short and disrupting question: Why?

Goal 1) I would like no leftover step from the build on one platform to be mistaken for an already performed step by the other platform

Clean the build directory after switching platforms or use a shadow build.

Goal 2) I would like no intermediate file to pollute the src dir

Use shadow build of qmake options for determining where intermediate files should go.

Goal 3) I would like to work from inside an IDE, Qt Creator being the obvious choice in this case.

Qt Creator is Open Source. If it doesn't suit your needs, modify it.

It seems to me a reasonable pretense, isn't it?

Yeah. I would like Qt Creator to make coffee so that I don't have to go to kitchen in the morning to make one myself (yes - I have a coffee machine and yes - I could bring it to my room. But I love Qt Creator, why didn't the Trolls think of adding coffee making features to it? It's an obvious thing, right?). Isn't it reasonable as well?

[miwarre]

A short and disrupting question: Why?

Because I want to test and debug the same app (same source code) under BOTH Windows and Linux.

If you are using a hammer to connect two planks with nails and then you decide to change the nails to screws, why do you keep using the hammer instead of a screwdriver?

If Qt Creator doesn't work for you then don't use it. Use proper tools for the job.

And

Qt Creator is Open Source. If it doesn't suit your needs, modify it.

You are right and it is definitely possible I will take either (or both) routes. But, if you are at a camp site and your Swiss army knife does 95% of what you need, for the missing 5% would you start by looking better into it to see if there is another blade you didn't notice, maybe asking your friends if they know a trick or two to get the job done with it, or by walking to the nearest town to get a new tool you would have then to learn how to use from scratch?

Qt Creator does get the great majority of the job done for me and I cannot claim to know everything of it (far from it!), so I started asking for help and suggestions about the few pieces missing (to me). If I sounded rude, this was completely unintentional and I am sorry, but I thought this was the right place where to ask.

Yeah. I would like Qt Creator to make coffee so that I don't have to go to kitchen in the morning to make one myself (yes - I have a coffee machine and yes - I could bring it to my room. But I love Qt Creator, why didn't the Trolls think of adding coffee making features to it? It's an obvious thing, right?). Isn't it reasonable as well?

You are right, so you may start coding coffee making features into it, can't you? It is open source after all...

M.

[wysota]

Because I want to test and debug the same app (same source code) under BOTH Windows and Linux.

But why do you want them to overwrite the same files? Is it that hard to call "make -f Makefile.windows" and "make -f Makefile.linux"? instead of just "make"? You can even make a script that will automatically call the right file...

You are right and it is definitely possible I will take either (or both) routes. But, if you are at a camp site and your Swiss army knife does 95% of what you need, for the missing 5% would you start by looking better into it to see if there is another blade you didn't notice, maybe asking your friends if they know a trick or two to get the job done with it, or by walking to the nearest town to get a new tool you would have then to learn how to use from scratch?

If I knew I have other tools I knew were suited better for the job in my other pocket I would ignore the knife and use the other tool.

Qt Creator does get the great majority of the job done for me and I cannot claim to know everything of it (far from it!), so I started asking for help and suggestions about the few pieces missing (to me). If I sounded rude, this was completely unintentional and I am sorry, but I thought this was the right place where to ask.

Qt Creator (or any other IDE) is not a panaceum, it's a tool. There is another tool called "make" (which is by the way used by Creator). Just use it properly.

You are right, so you may start coding coffee making features into it, can't you? It is open source after all...

That's the whole point: I already have a coffee machine, I don't need Creator to be one.

And please tell me why do you insist on testing/debugging in the same directory on all platforms. I simply can't understand that, it's completely impractical.

[miwarre]

OK, I'm suspecting this topic is starting to stink as the proverbial three-days-old fish. But I'm also suspecting there is something I can learn, as you seem so sure:

And please tell me why do you insist on testing/debugging in the same directory on all platforms. I simply can't understand that, it's completely impractical.

Of course it is! And it is not what I want to do. This is what I am (actually was: see below) trying to reach:

1) a directory with the sources of a project; I can access (for coding and compiling) this directory both through Win and through Linux. Let's call it "src".

2) a directory with the results (intermediate and final) of compilation under Win, let's call it "build_win".

3) a directory with the results (intermediate and final) of compilation under Linux, let's call it "build_linux".

1) is already set up.
2) is easy to achieve, in itself, using Qt Creator shadow build setting under Win.
3) is also easy to achieve in itself using the same setting under Linux.

I do not really care where "build_win" and "build_linux" are as far as they are separate from each other and from "src".

So, I'm very near to the goal: all the pieces are there. The only problem is that 2) and 3) cannot co-exist!

If I sets Qt Creator shadow build under Win to, say, "E:\Dev\MyProject\build_win", when I load the project under Linux, the setting is carried over and would point to an illegal directory name. And vice-versa.

I tried a number of combinations of settings in the .pro itself and none was successful because, as DigiDrag remarked at the beginning of this topic, at least the makefile is still placed in the src directory and it is not cleaned by clean. So that the second platform I build under will find an inappropriate makefile.

But you were right about looking for other tools: I probably reached (a decent approximation of) my goal by using svn: a local repository (which I already have anyway) accessed by two separate working copies under the two OS'es. Not as elegant, but clean, simple and safe enough.

Thanks,

M.

[wysota]

Eeeeh....

mkdir src
cd src
svn co ... .
ln -s myproject.pro myproject_lin.pro # -s is optional
cp myproject.pro.user myproject_lin.pro.user

mkdir src
cd src
svn co ... .
ln -s myproject.pro myproject_lin.pro # -s is optional
cp myproject.pro.user myproject_lin.pro.user

To copy to clipboard, switch view to plain text mode 

Now open myproject.pro from Windows and myproject_lin.pro from Linux. And I don't care that FAT/NTFS doesn't support links - use another filesystem.

Or of course:

cd build-lin
qmake ../src/myproject.pro

cd build-lin
qmake ../src/myproject.pro

To copy to clipboard, switch view to plain text mode 

Or:

DEPENDPATH += src
INCLUDEPATH += src
win32 {
  DESTDIR = build-win
  UI_DIR = build-win/ui
  OBJECTS_DIR = build-win/obj
  MOC_DIR = build-win/moc
}
unix {
  DESTDIR = build-lin
  UI_DIR = build-lin/.ui
  OBJECTS_DIR = build-lin/.obj
  MOC_DIR = build-lin/.moc
}

DEPENDPATH += src
INCLUDEPATH += src
win32 {
  DESTDIR = build-win
  UI_DIR = build-win/ui
  OBJECTS_DIR = build-win/obj
  MOC_DIR = build-win/moc
}
unix {
  DESTDIR = build-lin
  UI_DIR = build-lin/.ui
  OBJECTS_DIR = build-lin/.obj
  MOC_DIR = build-lin/.moc
}

To copy to clipboard, switch view to plain text mode 

But what do I know...

[KeyserSoze]

I just found this thread while searching for why QMAKE_MAKEFILE doesn't work in QtCreator. I also asked the same question in the freenode/#qtcreator irc channel, and after a suggestion received there, sent an email to the qtcreator mailing list:
http://lists.trolltech.com/pipermail...er/004288.html
Like I said in the email, I plan to modify the behavior of QtCreator so that it will pay attention to QMAKE_MAKEFILE, unless someone says why that would be a bad idea, or a regular developer beats me to the punch.

But what do I know...

wysota, I think your suggestions all would work fine for using qmake and make from the command line, the only issue is that it is difficult to get QtCreator to behave the same way. Your 2nd example, cd'ing to a directory and then invoking qmake, is exactly how I do this when I'm building from the command line (and the only way I did it before QtCreator existed). However, if you try to invoke qtcreator from that subdirectory, you run into problems because QtCreator doesn't seem to care where you invoke it from, it drops generated files in the same directory the .pro file resides in. Like others have said, you can override where all generated files will go using OBJECTS_DIR, DESTDIR, etc., but because QtCreator doesn't use the QMAKE_MAKEFILE variable, you cannot get it to build using the makefile you specify, even though it creates them as you specify.

- Miles

[wysota]

You have strange problems people... Seems that Qt tools like me more than you because I don't have problems with placing all the files wherever I want them to be.