qmake isuue with INSTALLS and INSTALL_ROOT

[mcarter]

I am trying to add an 'install' target to my project Makefile. When I try to use the INSTALLS mechanism of the .pro file to produce the install target, an $(INSTALL_ROOT) is always prefixed to the target.path I specify:


target.path = /$(DEPLOY_DIR)/bin

produces


-$(INSTALL_PROGRAM) "$(QMAKE_TARGET)" "$(INSTALL_ROOT)/$(DEPLOY_DIR) /bin/$(QMAKE_TARGET)"

The install I want to perform is not a system install but one based on the project directory tree I am working in, so the DEPLOY_DIR will usually specify a relative path.

I also have to prefix the .path with a '/' otherwise qmake will prefix the path with the current dir.
Can I get the install process just use the path I specify?

[wysota]

The install I want to perform is not a system install but one based on the project directory tree I am working in, so the DEPLOY_DIR will usually specify a relative path.
So why does the path start with a slash? This makes the path absolute.


I also have to prefix the .path with a '/' otherwise qmake will prefix the path with the current dir.
Which makes the path relative to the current dir. Isn't it what you want?

[mcarter]

So why does the path start with a slash? This makes the path absolute.

it needs the slash otherwise qmake forces the current path to be prepended to $(DEPLOY_DIR)


Which makes the path relative to the current dir. Isn't it what you want?

But that forces the actual current dir in the Makefile. I am trying to pass the $(DEPLOY_DIR) on thru to the Makefile. Then $(DEPLOY_DIR) can be used relative or absolute.

But I guess if the assumption is that make is always done after qmake then the install in the Makefile should have the required path. It would just be nice to take the path as specified. If I want to add the $(INSTALL_ROOT), I can add that myself.

[wysota]

But that forces the actual current dir in the Makefile.
That's the point.

I am trying to pass the $(DEPLOY_DIR) on thru to the Makefile. Then $(DEPLOY_DIR) can be used relative or absolute.
Your "DEPLOY_DIR" is qmake's "INSTALL_ROOT".

[mcarter]

Your "DEPLOY_DIR" is qmake's "INSTALL_ROOT".

yes, but I want it to use DEPLOY_DIR and not be forced to use INSTALL_ROOT, ie use the path that I specify. The qt items are a small piece of the overall project that is being built. This build process uses the DEPLOY_DIR variable to control where things go for the whole project. Since you cannot pass variables to qmake like you can with make, the env variable needs to be passed along to Makefile and then processed properly with the make command.

[wysota]

yes, but I want it to use DEPLOY_DIR and not be forced to use INSTALL_ROOT, ie use the path that I specify.
Hmm... Let's see... you have two variables and you want the content of one be present in the other... Hmm... how do you do that.... Hey, maybe you assign value of one to the other before calling make install?

INSTALL_ROOT=$DEPLOY_DIR make install

[mcarter]

Hmm... Let's see... you have two variables and you want the content of one be present in the other... Hmm... how do you do that.... Hey, maybe you assign value of one to the other before calling make install?

INSTALL_ROOT=$DEPLOY_DIR make install

I understand all that (been testing it that way), and that works great for the simple bash case especially when I am working in that dir, but again, this is one component in a much larger project build.

Now I must use something like this:

target.path = /bin
INSTALLS += target
And know that $(INSTALL_ROOT) will be prepended to the path and then inform the build team that an additional tag will need to be added to build this piece of software, instead of just the simple target.path = $(DEPLOY_DIR)/bin, which seems a lot more intuitive.

I appreciate the discussion wysota. I just find it a little frustrating sometimes how Qt ties your hands because that is how they expect it to be used.

[wysota]

I understand all that (been testing it that way), and that works great for the simple bash case especially when I am working in that dir, but again, this is one component in a much larger project build.
If this build is built by make then you can add a rule to the makefile that will set the value of INSTALL_ROOT before calling make install on this particular component.


I just find it a little frustrating sometimes how Qt ties your hands because that is how they expect it to be used.
If something does things differently than what you're used to, it doesn't mean it ties your hands in any way. I could say "it's frustrating how C ties your hands by not allowing you to overload functions" or "it's frustrating how British law ties your hands by forcing you to drive on the left side of the road". Different doesn't mean worse. What is a downside for you might be an advantage for someone else - for instance doing what you ask qmake to do would immediately discard the possibility of doing shadow builds installing files present in the source bundle that are not generated during compilation. qmake needs to be able to calculate absolute paths properly as relative paths are unreliable in many cases.

[mcarter]

If this build is built by make then you can add a rule to the makefile that will set the value of INSTALL_ROOT before calling make install on this particular component.

The project has developed a build mechanism using python. Does not look like adding a tag will be a problem, I was just hoping to avoid that.


for instance doing what you ask qmake to do would immediately discard the possibility of doing shadow builds installing files present in the source bundle that are not generated during compilation. qmake needs to be able to calculate absolute paths properly as relative paths are unreliable in many cases.
No it does not, I am just asking for a way to actually specify a path without qmake manipulating it in anyway . . . do not prepend INSTALL_ROOT, do not add current dir path . . . just take what I specify. Maybe with a no_install_prepend CONFIG item or just a target.install_root=$(MYDIR) option. If that is not used then use the default which is the way things are now.

btw, there is no mention of INSTALL_ROOT being used for INSTALLS. It was not until I looked at the generated Makefile that I even noticed this.

[wysota]

The project has developed a build mechanism using python. Does not look like adding a tag will be a problem, I was just hoping to avoid that.
Since Qt uses make, at some point you need to call make. And when doing that, you can assign the required variable.


No it does not, I am just asking for a way to actually specify a path without qmake manipulating it in anyway . . . do not prepend INSTALL_ROOT, do not add current dir path . . . just take what I specify. Maybe with a no_install_prepend CONFIG item or just a target.install_root=$(MYDIR) option. If that is not used then use the default which is the way things are now.
What you want is to do what INSTALL_ROOT does but you just want to call it differently. It's like you wanted to use Qt but you'd like it to be called Falafel because all your other libraries begin with "F". Fortunately you can do it - Qt is open-source so you can rebuild qmake and/or adjust its spec files in such a way that the "INSTALL_ROOT" variable will be called "DEPLOY_DIR". But don't ask or expect anyone to rename Qt to Falafel (or provide means to do it for the binary release) only because you or someone else likes the name better or that the name fits his purpose better. Maybe qmake allows you to rename "INSTALL_ROOT" to something else, that I do not know, I can only tell you where to look for it - in qmake spec files and in qmake source files.

[mcarter]

Since Qt uses make, at some point you need to call make. And when doing that, you can assign the required variable.
Right, got that and understand that. The project is adding another variable (INSTALL_ROOT) to the build . . . again I was hoping to avoid it.


It's like you wanted to use Qt but you'd like it to be called Falafel because all your other libraries begin with "F"..
Wow, that is not was I was asking. I was just saying it would be nice to have a qmake option to disable the hard-coded INSTALL_ROOT or set it or use another variable in its place since the install process is centered around this . . . an option. But I am happy to jump thru the Qt hoops to get this working since now I understand that is the way it works.

[wysota]

Right, got that and understand that. The project is adding another variable (INSTALL_ROOT) to the build . . . again I was hoping to avoid it.
I don't know how your build tool works but there is a good chance you don't need to do it. INSTALL_ROOT is a function of DEPLOY_DIR - f(x) = x, so it is not a new variable per se. The user doesn't need to set it anywhere as its value is determined by the value of DEPLOY_DIR.


Wow, that is not was I was asking. I was just saying it would be nice to have a qmake option to disable the hard-coded INSTALL_ROOT
Hardcoded INSTALL_ROOT is empty so you don't need to 'disable' it in any way. I don't know why you think it is bad, it's a standard approach for build tools to be able to use istall prefixes. autotools have something similar, just called differently. After all it is just a name, a meaningless label. You could probably even force make to substitute its value with value of another property automatically.

[mcarter]

I don't know how your build tool works but there is a good chance you don't need to do it.
Right, after looking at a second time, I can use target.path=/$(DEPLOY_DIR)/bin and as long as INSTALL_ROOT is never defined (which it looks like it is not for this project) and DEPLOY_DIR is an absolute path, then everything will work as is.


I don't know why you think it is bad, it's a standard approach for build tools to be able to use istall prefixes. autotools have something similar, just called differently.
Ah, that was the key. I guess we should have started there :D . . . or a better explanation of INSTALL_ROOT as with the DESTDIR of autotools.

I am a Makefile purist and always create my own Makefiles for my code. The software is run on the same type of system so it is "simpler" that way. Now with Qt it is much easier to use qmake and I was forcing the process to make Makefiles the way I expect them . . . maybe same reason I have been avoiding autotools. I also believe in using relative paths to keep things local, but that seems to go against how most build systems work, especially in terms of the install side of things.

Ok, I see the light.
wysota, thanks for talking this thru.