Skip to content

Fix libdir configuration option. #1919

Closed
wants to merge 1 commit into from

2 participants

@voxik
voxik commented Sep 21, 2012

The lib, kernel and runtime directories has to be placed in the same
folder. This issue was introduced due to fix for #1757 in 7862130#L10R346

@brixen
Rubinius member
brixen commented Sep 22, 2012

These should not be ||=, passing that option sets all those dirs relative to the directory passed.

@voxik
voxik commented Sep 22, 2012

Actually, I am thinking now about introducing something like "rubylibprefix" configuration options, similarly to MRI. I just not sure about the default valules yet.

The issue with libidir is, that standard autoconf libdir option traditionally specifies libdir such as /usr/lib or /usr/lib64 etc, but the semantics of Rubinius's libdir is more like /usr/lib/lib or better /usr/lib/rubinius/lib

@brixen
Rubinius member
brixen commented Sep 22, 2012

Yes, Rubinius "lib" dir is really like an application lib directory rather than a shared/static library directory. However, the context is pretty obvious and I don't think there's that much room for confusion. One concern is that once we provide a shared library for Rubinius, it could get confusing.

We could change it to --appdir.

@voxik
voxik commented Sep 22, 2012

I am trying to package Rubinius for Fedora and I'd like to use standard %configure macro, which is used for RPM packaging. This macro serves --libdir=/usr/lib64 to Rubinius's configuration script. I can override that macro to --libdir=/usr/lib64/rubinius/lib, but than I have to override kerneldir and runtimedir as well (not mentioning sitedir and vendordir). I believe that Rubinius should be placed into /usr/lib64/rubinius by default and libdir, runtimedir and kerneldir should be relative to that path. This could be achieved by introducing "rubylibprefix" or similar configuration option. I'll try to provide patch at Monday, unless you do it prior me ;)

@brixen
Rubinius member
brixen commented Sep 25, 2012

I'm not interesting in catering to any particular packaging system. Fedora is only one of many. The existing --libdir means something specific for Rubinius. We could change it to --appdir or we could append '/rubinius' to the value the user passes unless it ends with '/rubinius'.

@voxik
voxik commented Sep 26, 2012

Neither I am. I am looking for compatibility with autotools behavior, which are widely used for build configuration.

@voxik voxik Introduce --libprefixdir configuration option.
This configuration option allows to specify directory, into which will
be palced lib, kernel and runtime sub-directories, which have to be in the
same folder (this precondition was broken due to fix for #1757).

It alows to restore the standard meaning of --libdir configuration
option, i.e. the standard system library directory instead of location
of Rubinius lib sub-directory.

Runinius lib, kernel and runtime subdirectory names are not configurable
ATM.
41b4f47
@voxik
voxik commented Sep 27, 2012

I modified my commit. It keeps the current functionality, when no configuration option is specified. But it always keeps the lib, kernel and runtime on the same level and the names of the directories are not possible to change. Once the libdir is specified, it creates the "rubinius" subdirectory in it and place the rubinius libraries inside. Optionally, you can choose to specify different location for the libraries by --libprefixdir option (in this case, the --libdir is ignored).

@brixen brixen added a commit that closed this pull request Oct 3, 2012
@brixen brixen Changed configure --libdir to --appdir. Closes #1919.
The --libdir option is retained for specifying where to put the Rubinius
shared library. We don't build a shared or static library yet but we will
when we have an embedding API.

The --appdir option specifies where the application runtime and library
files will be installed. The use of --libdir for this was misleading.
510161a
@brixen brixen closed this in 510161a Oct 3, 2012
@voxik
voxik commented Oct 3, 2012

Well, the possible confusion of libdir is one think, but the other think which I was trying to solve is that lib, runtime and kernel directories have to be on the same level, e.g. if I specify --appdir=/foo/lib --runtimedir=/bar/runtime --kerneldir=/baz/kernel the rubinius will crash, while in contrary when specifying --appdir=/rubinius/lib --runtimedir=/rubinius/runtime --kerneldir=/rubinis/kernel the rubinius works just fine. Unfortunately I cannot find right now the offending require or load, which causes this troubles :/

@brixen
Rubinius member
brixen commented Oct 3, 2012

Why are you not just specifying --appdir? Why are you specifying different kernel and runtime dirs?

@voxik
voxik commented Oct 3, 2012

Sorry for confusion, I was wrong :/

But anyway. Your patch is missing one important thing in comparison to mine. There is no relation bewteen --appdir and --libdir. By default, it should be that --appdir = --libdir + 'rubinius'. Of course, specifying --appdir would result in ignoring the specified --libdir.

The point is that for packaging, I need to put all libraries into /usr/lib or /usr/lib64 depending on platform and for that, I'd like to use the --libdir.

I'll try to update my patch later.

BTW Please note that in my patch --libprefixdir == --appdir in yours. I chosen the name, since Ruby is using similarly named configuration option (--rubylibprefixdir if I am not mistaken).

@brixen
Rubinius member
brixen commented Oct 3, 2012

The --appdir and --libdir are not at all related. There is no requirement that the Ruby runtime and libraries are installed in the same location as binary static or shared object libraries. They are completely separate things. There is ultimately no requirement that Rubinius even use filesystem-based kernel and runtime.

@voxik
voxik commented Oct 4, 2012

So where would you put the appdir by default on FHS system? At now, you can use --prefix to specify that you want to put all the stuff into /usr and you get there created /usr/bin/, /usr/lib/, /usr/kernel/, /usr/runtime. That cannot be. So you would suggest me to use --appdir=/usr/lib/rubinius to get the structure which is feasible for FHS. But why should I do that explicitly? You don't have to specify to any other application "behave correctly and don't spread all your stuff randomly around the filesystem". I appreciate the --appdir in case I like to have rubinius in other directory, such as /usr/lib/rubinius20, but why you force me to use it by default?

@brixen
Rubinius member
brixen commented Oct 4, 2012

The question is, "does --appdir provide you what you need to satisfy your FHS requirements?" I believe it does. If it does not, explain how it doesn't and I'll fix it. You can also specify --prefix=/usr/local/rubinius, in which case everything would be under that and you can symlink to /usr/local/bin or override those particular paths.

FHS is one of many opinions about how to structure a file system. One, of many. Rubinius is not beholden to it.

@voxik
voxik commented Oct 4, 2012

As I told you ... I'd like to use standard configuration options, which are automatically feeded by Fedoras configuration macro. One of them is --libdir. If you would accept my patch, then it would be everything I need. In contrary, with the --appdir, the --libdir is completely useless and more over I have to specify one additional option.

Otherwise I agree with you regarding the FHS. FHS is structure which was chosen for Fedora and I try to make Rubiniuse's configuration flexible enough to satisfy every need.

@brixen
Rubinius member
brixen commented Oct 4, 2012

And as I have explained, --appdir and --libdir are completely separate. The use of --libdir was a mistake. That option must be available for where to put the static/shared object library (eg librubinius.a) and has nothing to do with the runtime and libraries, which need not necessarily exist as files at all, and soon Rubinius will have the ability to load kernel from the network.

I have heard and understood repeatedly that you wish to pass --libdir from Fedora stuff. It's the wrong option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.