VirtualBox

Opened 15 years ago

Closed 8 years ago

#3166 closed defect (obsolete)

build fails if INST_DLL and INST_BIN point to different paths

Reported by: Rogutės Owned by:
Component: other Version: VirtualBox 2.1.2
Keywords: install Cc:
Guest type: other Host type: other

Description (last modified by aeichner)

It would greatly ease packaging of virtualbox-ose, if one could build with, e.g.

$ kmk PATH_OUT="/staging_dir" INST_BIN=usr/bin/ INST_DLL=usr/lib/ INST_SYS=usr/lib/ INST_LIB=usr/lib/obj/ INST_SDK=usr/lib/sdk/

and it almost works, but build (uninformatively) fails whenever INST_BIN and INST_DLL point to different directories. Since other INST_* variables work, perhaps these could also be fixed?

On a similar note, should the compontents/ directory really go to INST_BIN and not to INST_LIB or smth.?

Change History (6)

comment:1 by Frank Mehnert, 15 years ago

Resolution: wontfix
Status: newclosed

Please don't change these variables. To change the target directory for the compiled binary, please have a look at the file debian/LocalConfig.kmk, especially the *PATH* variables at the end of that file. Copy that file one directory up and the directories should fit.

comment:2 by Rogutės, 15 years ago

Resolution: wontfix
Status: closedreopened

The problem is not the target directory - *PATH* variables work fine for this indeed.

The problem is the actual installation of files to the target directory (aka 'make install' step from autotools). Packaging for debian distributions isn't a problem, because you provide the needed scripts, but packagers for other distribution have to cherry-pick required files from PATH_OUT and put them to the corresponding directories (mostly /usr/bin, /usr/lib).

Doing this once is not that hard, but packagers have to manually check for changes with each new release of VirtualBox OSE, to avoid missing files.

When I checked for a more general way to do this, I've found that the INST_* variables mostly do the job. But since you said that packagers shouldn't touch them, perhaps my report could be (de/pro)moted to a request for a 'make install' step?

comment:3 by Frank Mehnert, 15 years ago

I'm not sure if you understood me. Did you actually have a look at debian/LocalConfig.kmk? Note VBOX_PATH_APP_PRIVATE, VBOX_PATH_APP_DOCS, VBOX_PATH_SHARED_LIBS and VBOX_PATH_APP_PRIVATE_ARCH. IMO it does not make sense to put the VirtualBox .so libraries into /usr/lib because these libraries will not be used by any other application. Therefore the proposed place is /usr/lib/virtualbox.

Again, please don't modify the INST_* variables but modify the variables which you can find in debian/LocalConfig.kmk.

comment:4 by Rogutės, 15 years ago

Yes, we are mis-communicating somewhere. It is clear now that I shouldn't be touching the INST_* variables, and my initial report is wrong. Also, I might be missunderstanding something obvious... But let's try a shell language:

cd VirtualBox-2.1.2_OSE
cp debian/LocalConfig.kmk .
./configure
source env.sh
kmk
cd out/linux.x86/release

After successfully running this I want to package VirtualBox for my distribution of choice, thus I have to manually move many files from bin/*, lib/* directories, e.g.

mv bin/*.so $(prefix)/usr/lib/virtualbox/
mv bin/VBoxSDL $(prefix)/usr/bin/

and then prepare a package from my $(prefix) staging dir.

Now I believe that moving the files to my staging dir should be handled by a scriptlet prepared by the developers, because they know best which files are required and which not. Currently, the debian/rules script does this, but it is obviously only useful for debian based distributions. What about other distributions? What about a step similar to make install from autotools?

Thanks.

comment:5 by Frank Mehnert, 15 years ago

Right, that step is still necessary and I think we should add some generic Makefile target.

comment:6 by aeichner, 8 years ago

Description: modified (diff)
Resolution: obsolete
Status: reopenedclosed

Please reopen if still relevant with a recent VirtualBox release.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use