waf should have an option for the dir to install perl files and do not glob.
Created attachment 9730 [details] v4-0-test and v4-1-test patch
Comment on attachment 9730 [details] v4-0-test and v4-1-test patch We need an additional patch for Yapp.
Created attachment 9731 [details] v4-0-test and v4-1-test patch
Comment on attachment 9731 [details] v4-0-test and v4-1-test patch I think --with-perl-vendordir should be --with-perl-vendorlib and the default should be read_out('print $Config{vendorlib}')[0] The buildtools/wafadmin/ change should be in its own commit
read_out('print $Config{vendorlib}')[0] will not work in autobuild! A user can't install to /usr/share/perl5/vendor_lib. Kai wanted it to be in the installation path cause you can set $PERL5LIB. The same would apply to python ... I used --with-perl-vendordir to be the same pattern as think --with-perl-archdir.
(In reply to comment #5) > read_out('print $Config{vendorlib}')[0] will not work in autobuild! A user > can't install to /usr/share/perl5/vendor_lib. Kai wanted it to be in the > installation path cause you can set $PERL5LIB. The same would apply to python > ... > > > I used --with-perl-vendordir to be the same pattern as think > --with-perl-archdir. No, that uses if getattr(Options.options, 'perlarchdir', None): conf.env.ARCHDIR_PERL = Options.options.perlarchdir else: conf.env.ARCHDIR_PERL = read_out('print $Config{sitearch}')[0] While you just used: conf.env.VENDORDIR_PERL = Options.options.perlvendordir
(In reply to comment #6) > (In reply to comment #5) > > read_out('print $Config{vendorlib}')[0] will not work in autobuild! A user > > can't install to /usr/share/perl5/vendor_lib. Kai wanted it to be in the > > installation path cause you can set $PERL5LIB. The same would apply to python > > ... > > > > > > I used --with-perl-vendordir to be the same pattern as think > > --with-perl-archdir. > > No, that uses > > if getattr(Options.options, 'perlarchdir', None): > conf.env.ARCHDIR_PERL = Options.options.perlarchdir > else: > conf.env.ARCHDIR_PERL = read_out('print $Config{sitearch}')[0] > > While you just used: > > conf.env.VENDORDIR_PERL = Options.options.perlvendordir Also ${DATAROOTDIR}/perl5/vendor_perl, which typically leads to /usr/share/perl5/vendor_perl is not always the correct path. On my ubuntu 12.04 system I have 'vendorlib' => '/usr/share/perl5'.
(In reply to comment #6) > (In reply to comment #5) > > read_out('print $Config{vendorlib}')[0] will not work in autobuild! A user > > can't install to /usr/share/perl5/vendor_lib. Kai wanted it to be in the > > installation path cause you can set $PERL5LIB. The same would apply to python > > ... > > > > > > I used --with-perl-vendordir to be the same pattern as think > > --with-perl-archdir. > > No, that uses > > if getattr(Options.options, 'perlarchdir', None): > conf.env.ARCHDIR_PERL = Options.options.perlarchdir > else: > conf.env.ARCHDIR_PERL = read_out('print $Config{sitearch}')[0] The options default is None. So by default it uses the sitearch directory, which is e.g. /usr/lib64/perl5/sitearch. I've tried to push something like that to autobuild it failed cause it can't install to /usr !!! > While you just used: > > conf.env.VENDORDIR_PERL = Options.options.perlvendordir Yes, cause the option has a default. Which is default='${DATAROOTDIR}/perl5/vendor_perl'
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > read_out('print $Config{vendorlib}')[0] will not work in autobuild! A user > > > can't install to /usr/share/perl5/vendor_lib. Kai wanted it to be in the > > > installation path cause you can set $PERL5LIB. The same would apply to python > > > ... > > > > > > > > > I used --with-perl-vendordir to be the same pattern as think > > > --with-perl-archdir. > > > > No, that uses > > > > if getattr(Options.options, 'perlarchdir', None): > > conf.env.ARCHDIR_PERL = Options.options.perlarchdir > > else: > > conf.env.ARCHDIR_PERL = read_out('print $Config{sitearch}')[0] > > > > While you just used: > > > > conf.env.VENDORDIR_PERL = Options.options.perlvendordir > > Also ${DATAROOTDIR}/perl5/vendor_perl, which typically leads to > /usr/share/perl5/vendor_perl is not always the correct path. > On my ubuntu 12.04 system I have 'vendorlib' => '/usr/share/perl5'. That's why I added an option so a packager can correctly specify the correct directory! If you want read_out('print $Config{vendorlib}')[0] to be the default, you need to change autobuild and the buildfarm first!
Am 28.02.2014 11:43, schrieb samba-bugs@samba.org: > https://bugzilla.samba.org/show_bug.cgi?id=10472 > > --- Comment #8 from Andreas Schneider <asn@samba.org> 2014-02-28 10:43:33 UTC --- > (In reply to comment #6) >> (In reply to comment #5) >>> read_out('print $Config{vendorlib}')[0] will not work in autobuild! A user >>> can't install to /usr/share/perl5/vendor_lib. Kai wanted it to be in the >>> installation path cause you can set $PERL5LIB. The same would apply to python >>> ... >>> >>> >>> I used --with-perl-vendordir to be the same pattern as think >>> --with-perl-archdir. >> >> No, that uses >> >> if getattr(Options.options, 'perlarchdir', None): >> conf.env.ARCHDIR_PERL = Options.options.perlarchdir >> else: >> conf.env.ARCHDIR_PERL = read_out('print $Config{sitearch}')[0] > > The options default is None. So by default it uses the sitearch directory, > which is e.g. /usr/lib64/perl5/sitearch. I've tried to push something like that > to autobuild it failed cause it can't install to /usr !!! Then we need to explicitly specify it in autobuild, like we specify --prefix. metze
(In reply to comment #9) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #5) > > > > read_out('print $Config{vendorlib}')[0] will not work in autobuild! A user > > > > can't install to /usr/share/perl5/vendor_lib. Kai wanted it to be in the > > > > installation path cause you can set $PERL5LIB. The same would apply to python > > > > ... > > > > > > > > > > > > I used --with-perl-vendordir to be the same pattern as think > > > > --with-perl-archdir. > > > > > > No, that uses > > > > > > if getattr(Options.options, 'perlarchdir', None): > > > conf.env.ARCHDIR_PERL = Options.options.perlarchdir > > > else: > > > conf.env.ARCHDIR_PERL = read_out('print $Config{sitearch}')[0] > > > > > > While you just used: > > > > > > conf.env.VENDORDIR_PERL = Options.options.perlvendordir > > > > Also ${DATAROOTDIR}/perl5/vendor_perl, which typically leads to > > /usr/share/perl5/vendor_perl is not always the correct path. > > On my ubuntu 12.04 system I have 'vendorlib' => '/usr/share/perl5'. > > That's why I added an option so a packager can correctly specify the correct > directory! > > If you want read_out('print $Config{vendorlib}')[0] to be the default, you need > to change autobuild and the buildfarm first! Then we need to do that:-)
What I'm worried about in that respect is that this breaks the use case of not having to be root to install to a --prefix I own as a user.
(In reply to comment #12) > What I'm worried about in that respect is that this breaks the use case of not > having to be root to install to a --prefix I own as a user. You can still do that. You just have to specify --with-perl-vendorlib=/my/own/prefix/share/perl5
(In reply to comment #13) > (In reply to comment #12) > > What I'm worried about in that respect is that this breaks the use case of not > > having to be root to install to a --prefix I own as a user. > > You can still do that. You just have to specify > --with-perl-vendorlib=/my/own/prefix/share/perl5 We could also do some tricks comparing vendorprefix with vendorlib and append the difference to our 'prefix'. My ubuntu 12.04 has 'vendorprefix' => '/usr', 'vendorlib' => '/usr/share/perl5', 'vendorarch' => '/usr/lib/perl5', This could then result in default of ${prefix}/share/perl5 for vendorlib and ${prefix}/lib/perl5 for vendorarch. I'm not sure I really like it, but that could be possible... Or we check if vendorprefix doesn't match our prefix and give an error and enforce that --with-perl-vendorlib is explicitly specified.
New patchset ... https://git.samba.org/?p=asn/samba.git;a=shortlog;h=refs/heads/pidl-waf
Created attachment 9753 [details] v4-1-test patch
Created attachment 9754 [details] v4-0-test patch The pidl patches applied cleanly the autobuild script needed some fixing to apply.
(In reply to comment #17) > Created attachment 9754 [details] > v4-0-test patch > > The pidl patches applied cleanly the autobuild script needed some fixing to > apply. Pushed patchsets to autobuild-v4-1-test and autobuild-v4-0-test.
Pushed to v4-1-test and v4-0-test. Closing out bug report. Thanks!
I believe that the fix for this bug is what is causing configure to blow up. We have a site compiled Perl installed, built mostly with the default configuration. From perl -V I get: @INC: /opt/local/lib/perl5/5.8.9/i86pc-solaris /opt/local/lib/perl5/5.8.9 /opt/local/lib/perl5/site_perl/5.8.9/i86pc-solaris /opt/local/lib/perl5/site_perl/5.8.9 . Configure dies with the following traceback: Traceback (most recent call last): File "./buildtools/bin/waf", line 76, in <module> Scripting.prepare(t, cwd, VERSION, wafdir) File "/home/projects/tools/samba/samba-4.1.7.i386gcc.pt/buildtools/wafadmin/Scripting.py", line 145, in prepare prepare_impl(t, cwd, ver, wafdir) File "/home/projects/tools/samba/samba-4.1.7.i386gcc.pt/buildtools/wafadmin/Scripting.py", line 135, in prepare_impl main() File "/home/projects/tools/samba/samba-4.1.7.i386gcc.pt/wscript", line 280, in main wildcard_main(wildcard_cmd) File "./buildtools/wafsamba/samba_wildcard.py", line 110, in wildcard_main fun(ctx) File "/home/projects/tools/samba/samba-4.1.7.i386gcc.pt/buildtools/wafadmin/Scripting.py", line 241, in configure conf.sub_config(['']) File "/home/projects/tools/samba/samba-4.1.7.i386gcc.pt/buildtools/wafadmin/Configure.py", line 237, in sub_config self.recurse(k, name='configure') File "/home/projects/tools/samba/samba-4.1.7.i386gcc.pt/buildtools/wafadmin/Utils.py", line 634, in recurse f(self) File "/home/projects/tools/samba/samba-4.1.7.i386gcc.pt/wscript", line 140, in configure conf.RECURSE('pidl') File "./buildtools/wafsamba/samba_utils.py", line 469, in RECURSE return ctx.sub_config(relpath) File "/home/projects/tools/samba/samba-4.1.7.i386gcc.pt/buildtools/wafadmin/Configure.py", line 237, in sub_config self.recurse(k, name='configure') File "/home/projects/tools/samba/samba-4.1.7.i386gcc.pt/buildtools/wafadmin/Utils.py", line 634, in recurse f(self) File "/home/projects/tools/samba/samba-4.1.7.i386gcc.pt/pidl/wscript", line 33, in configure conf.check_perl_ext_devel() File "/home/projects/tools/samba/samba-4.1.7.i386gcc.pt/buildtools/wafadmin/Tools/perl.py", line 104, in check_perl_ext_devel conf.env.PERL_VENDORARCH_DIR = read_out('print $Config{vendorarch}')[0] IndexError: list index out of range If I add --with-perl-vendorarch=/opt/local/lib/perl5/site_perl/5.8.9/i86pc-solaris and --with-perl-vendorlib=/opt/local/lib/perl5/site_perl/5.8.9 to the configure command then configure works. This was previously not necessary. In any case, configure should not blow up in this manner.
Tom, can you test the patch here: https://git.samba.org/?p=asn/samba.git;a=shortlog;h=refs/heads/perl_dectection
The patched 4.1.7 configures, builds and installs without error. It installs the perl stuff in prefix/lib/perl5 Previous versions of Samba installed the perl stuff in prefix/share/perl5
I should add that if the perl module is installed in /opt/local/lib/perl5/site_perl/5.8.9 (part of our @INC), configure does find it and outputs the message: Checking for perl module Parse::Yapp::Driver 1.05 : ok
*** Bug 10602 has been marked as a duplicate of this bug. ***
Created attachment 9933 [details] Additional patches for v4-1-test
Created attachment 9934 [details] Additional patches for v4-0-test
I tried the latest patch against 4.1.7. The output of configure changed as follows: + Checking for perl $Config{vendorarch}: : not found + Checking for perl $Config{sitearch}: : '/opt/local/lib/perl5/site_perl/5.8.9/i86pc-solaris' + PERL_ARCH_INSTALL_DIR: : '/opt/local/lib/perl5/site_perl/5.8.9/i86pc-solaris' + Checking for perl $Config{vendorlib}: : not found + Checking for perl $Config{sitelib}: : '/opt/local/lib/perl5/site_perl/5.8.9' + PERL_LIB_INSTALL_DIR: : '/opt/local/lib/perl5/site_perl/5.8.9' + Checking for perl $Config{vendorarch}: : not found + Checking for perl $Config{sitearch}: : '/opt/local/lib/perl5/site_perl/5.8.9/i86pc-solaris' + PERL_ARCH_INSTALL_DIR: : '/opt/local/lib/perl5/site_perl/5.8.9/i86pc-solaris' + Checking for perl $Config{vendorlib}: : not found + Checking for perl $Config{sitelib}: : '/opt/local/lib/perl5/site_perl/5.8.9' + PERL_LIB_INSTALL_DIR: : '/opt/local/lib/perl5/site_perl/5.8.9' And the perl module is now installed in opt/local/lib/perl5/site_perl/5.8.9/Parse
Comment on attachment 9934 [details] Additional patches for v4-0-test LGTM
Karolin, please add the additional patches!
(In reply to comment #29) > Karolin, please add the additional patches! Pushed additional patches to autobuild-v4-[0|1]-test.
(In reply to comment #30) > (In reply to comment #29) > > Karolin, please add the additional patches! > > Pushed additional patches to autobuild-v4-[0|1]-test. Pushed to both branches. Closing out bug report. Thanks!
Possibly unrelated, but current master's "make install" does not respect --prefix for pidl anymore. It always wants to install in system directories, although --prefix was given. This breaks non-root make install. Sure, you can make it install somewhere else with special configure options. But these options must default to something under --prefix.
Assigning to Andreas who has brought up this topic initially
Setting to critical. With this new policy, Samba ignores --prefix by default for pidl. This makes it impossible to run "make install" as non-root. Also it is impossible to install more than one independent Samba installation in independent subdirectories.
(In reply to comment #34) > Setting to critical. With this new policy, Samba ignores --prefix by default > for pidl. This makes it impossible to run "make install" as non-root. Also it > is impossible to install more than one independent Samba installation in > independent subdirectories. We have explicit --with-perl-lib-install-dir= and --with-perl-arch-install-dir= as workarround. But we should fix this by comparing INSTALL_FILES() should take a perl_fixup similar to python_fix in order to inject an rpath to the installed binary. We could then compare perl's vendorprefix with our prefix and only use the perl provided default paths if they match.
(In reply to comment #35) > We have explicit --with-perl-lib-install-dir= and --with-perl-arch-install-dir= > as workarround. But we should fix this by comparing > > INSTALL_FILES() should take a perl_fixup similar to python_fix in order > to inject an rpath to the installed binary. We could then > compare perl's vendorprefix with our prefix and only use the perl provided > default paths if they match. If nobody finds the time to do it before the release of 4.2, I would vote to not install pidl at all in the default build.
This was working reasonably well when we were just invoking Makefile.PL from waf. Why did we move to using waf to install these files? Please don't remove the installation of Pidl. We rely on it in the Debian packages.
Michael, could you please backport the patches you created for this bug report? Thanks!
Created attachment 10423 [details] possible patchset for v4-1-test Patches for v4-1-test, cherry-picked from master. This patchset is the complete story, including the required fixes for the dependencies for SAMBA_GENERATOR. It also moves all the changes for this defect to wafsamba and restores wafadmin into the original state. Note: In order to be able to cleanly pick the patches I have picked four initial patches to docs/dynconfig by Garming and Andrew. Is this OK? Desirable? Undesirable? Comments please ... Michael
Created attachment 10427 [details] Final patchset for v4-1-test
Created attachment 10428 [details] Final patchset for v4-0-test
Karo, please push the "Final patchset..." attachments to 4.1 and 4.0, respectively. Thanks - Michael
(In reply to Michael Adam from comment #42) Pushed to autobuild-v4-[0|1]-test.
(In reply to Karolin Seeger from comment #43) Pushed to both branches. Closing out bug report. Thanks!