'make install' does not install files
Brought to you by:
cannam
Menu
▾
▴
#247 'make install' does not install files
I'm trying hard to package 3.0.3 for Arch Linux atm, but 'make install' does not install files to where you select it with configure, e.g.:
./configure --prefix=/usr
make
make install
does not install to /usr/bin/ but to /usr/local/bin (or rather tries to and then fails).
Even if I set all other configure flags for the directories, all of it is not applied!
This is quite frustrating to use and especially to package...
I can't be expected to pick up every single file and put it in the file system myself, am I?
Seems this is connected to:
https://sourceforge.net/p/sv1/bugs/234/
and
https://sourceforge.net/p/sv1/bugs/238/
Please fix the build system!
This and the other two should be fixed in the current hg default branch - but my working hours have been mostly allocated to server/devops tasks for the past couple of months and haven't yet had an opportunity to do the cross-platform test/build/package process necessary for a 3.0.4 build with these fixes in, or to isolate any Linux-build-only fixes for a platform-specific point release.
(comment edited to soften it a bit - it's not that I've had no time, just not the proper space to get back to grips with an SV release)
Last edit: Chris Cannam 2017-12-05
Okay, I'll fix it by script in the meantime.
If I move the files sv works otherwise!
Please try this again with v3.1.
Well, nothing has changed. The install target does nothing. Neither with nor without
DESTDIRset. I still have to install everything by hand.Oh, that is disappointing - I thought this was confirmed fixed, in the duplicate issue #234.
I just tested it myself with the release tarball and it worked here. I used
qmake -r,make,sudo make installand the last few commands run wereleaving the following in
/usr/local/binHow does the
make installprocess end, when you run it? What doesMakefile.svhave in it, in the end section after the### Installcomment header?I realise that wasn't a very good example because I forgot to change the install prefix, which is part of the substance of this report. However, I just tried it again with an arbitrary install prefix supplied to
./configure --prefix=(using a new directory created for the purpose) and it still worked fine, installing to the supplied target, so I'm still puzzled!Last edit: Chris Cannam 2018-07-17
I followed
INSTALL.txtand used./configure --prefix=/usr && make && make install DESTDIR="${pkgdir}/"(in a nutshell,$pkgdiris where the package contents are supposed to be installed to).However build runs fine, but this is the install target then:
I guess this means
DESTDIRis still ignored, as the target is trying to install to my root file system!qmake for some reason doesn't work for me
./configure --prefix=/usr && qmake{-qt5 {-makefile,-r}} && make installjust stops:So I don't even get to
make installhere.Related
Files: files
OK, thanks.
So in the first case you ran
configurewith a certain prefix, thenmakeandmake install, and the files were installed to the prefix that you had provided toconfigure. (Or they would have been installed there, if you had had permission.)That means the bug as described looks to be fixed, since the initial report was that
make installignored the prefix supplied toconfigure.The reason the second example fails to build is that
qmaketries to guess the project file name based on the current directory name - so if you are running from a directory calledsonic-visualiser-3.1but the project file issonic-visualiser.pro, then you need to provide that filename explicitly as an argument toqmake. Sorry I didn't mention that in my brief summary earlier.We seem to have the same situation both here and in the related #234. In both cases, a bug report was opened about the install process, I (eventually!) fixed the bug as reported, and then there turned out to be an issue with DESTDIR as well. Unfortunately neither report mentioned DESTDIR until after I had addressed the initial bug, and so I had never made any attempt to fix anything related to it.
I suggest (as I did in #234) that we need a separate issue to track DESTDIR usage, with an example of what behaviour is expected.
Last edit: Chris Cannam 2018-07-18
Well, yes and no. The title of this bug report still applies.
However, I have opened the more specific #254 for tracking work on implementing
DESTDIR.OK, thanks. Since the problem as initially described is solved, there is a new issue for the remaining problem, and this entry is now rather long, I'm closing this one.