Re: File::ShareDir - Outstanding modernization
Hi all, I re-ordered the quotes to avoid sending multiple replies but answer in order. 2015-05-04 16:34 GMT+02:00 Jens Rehsack rehs...@gmail.com: Hi, initially planned being one big topic for my QAH attendance, but Murphy decided to keep me busy otherwise (broken car, for everyone who didn't recognize on QAH...). Well - things are settling meanwhile and I have a few moments to think about the tasks I missed to finish in Berlin. One is File::ShareDir. The intension is to let File::ShareDir get closer to File::ConfigDir (and later let File::ConfigDir steal some features from File::ShareDir). The longterm goal is having it behave a bit more like share is intended (read until end of mail - don't scream here). There is no plan to break backwards compatibility (and if it happens on accident, the intension is to fix it and hopefully detect before it happens). Back to ideas for File::ShareDir: 1) analogous to File::ConfigDir have a bunch of share-dir prefixes including existing prefixes (core_share_dir, site_share_dir, vendor_share_dir, ...) and new ones (system_share_dir, machine_share_dir, here_share_dir, ...). == here is can be sane to have plugins like https://metacpan.org/release/File-ConfigDir-Plack for $ENV based locations (eg. FOO_BASE) or framework related extension. 2) Upon the prefixes, the dist_dir(), module_dir() will calculate the Full Qualified Share Dir as requested. It'll very likely to have other preferences is prefix picking for legacy API and new API (- 3) 3) introduce better accessors (dist_share_dir, module_share_dir, app_share_dir, dist_config_dir, module_config_dir, ...). The goal is allow a module access share-dirs from different applications (eg. templates to process) or let applications rely on different immutable files from several distributions (think LaTeX as an example). On Tue, May 5, 2015 at 6:14 AM, Olivier Mengué olivier.men...@gmail.com wrote: Hi, Is it really necessary to introduce those new features (bloat?) in the existing File::ShareDir ? I think so. Reason follows ... Why not just fork and keep the original File::ShareDir light? What problems would be solved if the new features you plan were added to the existing File::ShareDir? Which existing application would benefit from these change just by upgrading to that new File::ShareDir, without using the new APIs? The original File::ShareDir isn't that light. The reason for reworking File::ShareDir is the missing support for a real share concept which confuses more end-users. Many (but not even close to all) Experienced developers understand the pitfalls and manage to deal with that. So introducing the support as intended is from my point of view necessary, while supporting existing API. That's not bloated. On Tue, May 5, 2015 at 2:35 PM Karen Etheridge p...@froods.org wrote: I am not opposed in principle to redesigning File::ShareDir, but I want to be *very* clear about the proposed design changes, impact on various parts of the toolchain, and back-compatibility concerns before anything moves beyond the design phase. This is the intension of this thread. First discussing design details - on a probably very abstract level. Depending on the discussion we might need a more details design discussion or we can directly move to code (in a branch!). This code sits at the very heart of the cpan, called directly by ExtUtils::MakeMaker. You're not talking about https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/21, do you? Am 06.05.2015 um 02:33 schrieb breno oainikus...@gmail.com: Hi Jens! I'd love to have a module providing an improved and modern interface to File::ShareDir and I think the entire community would greatly benefit from it - not just the toolchain. That said, I would rather see it in a new module than have it in File::ShareDir itself. Kinda like how nowadays I prefer Path::Tiny over File::Spec + Cwd (or even Path::Class). We can talk about a simplified interface on top of such low-level classes. Maybe it is a sane proposal to avoid to much new public API but accessors for a module on top of this. Can you imagine creating a proposal for such a high-level module which maybe covers ShareDir and ConfigDir for eg. an CLI application like App::Math::Tutor and a Web-Application using templates (not design!) in share and a configuration in etc/ telling where the web-root is, the share-name (referring to my app_dir proposal). Cheers -- Jens Rehsack - rehs...@gmail.com
Re: File::Temp/File::Spec problems on Windows under taint mode – breaking change needed?
Am 27.04.2015 um 22:29 schrieb Graham Knop ha...@haarg.org: On 4/27/15 4:10 PM, Jens Rehsack wrote: Am 24.04.2015 um 05:37 schrieb Aristotle Pagaltzis pagalt...@gmx.de: * David Golden x...@xdg.me [2015-04-23 17:40]: [...] Please see https://rt.cpan.org/Ticket/Display.html?id=60340 for context. I think File::Temp needs to be able to work around File::Spec::Win32 returning a non-writable directory. My proposal was to warn and fall back to .. That's a small breaking change, but I think doing something in a different place than requested is better than failing entirely. Alternatively, it needs to validate the Win32 response and throw an error early, before attempting to make the directory so that the error message is more informative. Thoughts? Windows considers the current directory an implied part of %PATH%, True has no concept like the executable bit of Unixoid OSes, Nope - it has such a concept, but it's in ACL's, not in attributes. History of Windows was non-multi-user *shrug* - weird implementation, crummy supported ;) This also depends on the filesystem, and isn't really the same concept. Not the same concept, but a concept like executable bits on Unices. It is possible (investing enough effort) to implement a simplified access. Since POSIC specifies ACL's meanwhile showing that the idea itself wasn't that wrong (and ACL's i-node attributes, if any). But there is no reason to fight this - the result stays the same whatever we finally agree ;) nor does it allow unlinking files while they’re open. Depends on Filesystem ... So I’d feel uncomfortable about just unexpectedly dropping junk into the current directory, announced or not. Therefore I’d tend toward the latter. Is there a reason not to tryout Win32 API function GetTempPath (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364992%28v=vs.85%29.aspx)? I dunno how File::Spec/File::Temp on Unix behaves tmp points to a non-writable directory (think r/o file-system). This uses the environment just like File::Spec-tmpdir does. The only important difference is that File::Temp checks for tainting. Switching to GetTempPath would be the same thing as removing the taint checks. IIRC it checks some more and has %system%/temp as fallback. As non-native speaker (checked several translations) I don't get the sanity of tainting at all. But someone with better instincts for Windows may be able to call this bunk. Mostly I didn’t want to leave the question warnocked. I agree - '.' is the worst choice one can make - and I intend to say 'start again with TMP=.' or so. The closest thing I can think of would be using the local application data directory. This is the same place that the user's temp directory lives. Win32::GetFolderPath(Win32::CSIDL_LOCAL_APPDATA).\\Temp should give you the current user's temp directory. It would probably be wrong for programs not running under a login user account, like daemons or CGI scripts. Those would likely want to fall back to C:\WINDOWS\Temp. /me nods - that's fine at all. Cheers -- Jens Rehsack rehs...@gmail.com
Re: File::Temp/File::Spec problems on Windows under taint mode – breaking change needed?
Am 24.04.2015 um 05:37 schrieb Aristotle Pagaltzis pagalt...@gmx.de: * David Golden x...@xdg.me [2015-04-23 17:40]: [...] Please see https://rt.cpan.org/Ticket/Display.html?id=60340 for context. I think File::Temp needs to be able to work around File::Spec::Win32 returning a non-writable directory. My proposal was to warn and fall back to .. That's a small breaking change, but I think doing something in a different place than requested is better than failing entirely. Alternatively, it needs to validate the Win32 response and throw an error early, before attempting to make the directory so that the error message is more informative. Thoughts? Windows considers the current directory an implied part of %PATH%, True has no concept like the executable bit of Unixoid OSes, Nope - it has such a concept, but it's in ACL's, not in attributes. History of Windows was non-multi-user *shrug* - weird implementation, crummy supported ;) nor does it allow unlinking files while they’re open. Depends on Filesystem ... So I’d feel uncomfortable about just unexpectedly dropping junk into the current directory, announced or not. Therefore I’d tend toward the latter. Is there a reason not to tryout Win32 API function GetTempPath (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364992%28v=vs.85%29.aspx)? I dunno how File::Spec/File::Temp on Unix behaves tmp points to a non-writable directory (think r/o file-system). But someone with better instincts for Windows may be able to call this bunk. Mostly I didn’t want to leave the question warnocked. I agree - '.' is the worst choice one can make - and I intend to say 'start again with TMP=.' or so. Cheers -- Jens Rehsack rehs...@gmail.com
Preparation for Berlin - Compiler Checks requirements
Compiler Check Requirements.pdf Description: Adobe PDF document @Leont: You wanted me to review ExtUtils::Builder - can you point me to the right place? For Config::AutoConf, all is contained in https://github.com/ambs/Config-AutoConf Cheers -- Jens Rehsack rehs...@gmail.com
Re: Integrating C::AC into MakeMaker/MB
Am 09.12.2014 um 23:30 schrieb Leon Timmermans faw...@gmail.com:
On Tue, Dec 2, 2014 at 10:45 AM, Jens Rehsack rehs...@gmail.com wrote:
Seems reasonable - but as you know in not to distant future, they shall
also override CC, CCLD, ... (using ExtUtils::Builder or alike, instead
of plain cc).
Does the return hash of this callback overrides all EU::MM constants?
I think I can answer this question on my own:
File-ConfigDir-Install sno$ git diff
diff --git a/t/01-makefile.t b/t/01-makefile.t
index 5e9bd38..2b0759c 100644
--- a/t/01-makefile.t
+++ b/t/01-makefile.t
@@ -35,8 +35,12 @@ delete $ENV{PERL_MM_OPT}; # local::lib + PREFIX below
will FAIL
WriteMakefile(
NAME = 'File::ConfigDir::Install',
VERSION_FROM = 'lib/File/ConfigDir/Install.pm',
+CONFIGURE = sub {
+ {
INST_ETC = tlib-$$/etc,
INST_LIB = tlib-$$/lib,
+ },
+},
MAKEFILE = $FILE,
PREREQ_PM = {},
($] = 5.005 ?
$ make perl -Mblib t/01-makefile.t
cp lib/File/ConfigDir/Install.pm blib/lib/File/ConfigDir/Install.pm
Manifying 1 pod document
'INST_ETC' is not a known MakeMaker parameter name.
Generating a Unix-style test-21206-Makefile
Writing test-21206-Makefile for File::ConfigDir::Install
Writing MYMETA.yml and MYMETA.json
ok 1 - Created test-21206-Makefile
ok 2 - Recognized: t/etc/fsd-install.json
# make -f test-21206-Makefile
# cp t/etc/fsd-install.json tlib-21206/etc/fsd-install.json
# Manifying 1 pod document
ok 3 - Copied to blib for dist: t/etc/fsd-install.json
ok 4 - Same content: t/etc/fsd-install.json
# make -f test-21206-Makefile
DESTDIR=/var/folders/5s/sk58jrwj7jj73phc9lcx9nh8gn/T/cgOOrG5f45 install
# Skip tlib-21206/etc/fsd-install.json (unchanged)
# Manifying 1 pod document
# Installing
/var/folders/5s/sk58jrwj7jj73phc9lcx9nh8gn/T/cgOOrG5f45/Users/sno/perl5/perlbrew/perls/perl-5.20.0/man/man3/File::ConfigDir::Install.3
# Installing
/var/folders/5s/sk58jrwj7jj73phc9lcx9nh8gn/T/cgOOrG5f45/Users/sno/perl5/perlbrew/perls/perl-5.20.0/etc/fsd-install.json
# Appending installation info to
/var/folders/5s/sk58jrwj7jj73phc9lcx9nh8gn/T/cgOOrG5f45/Users/sno/perl5/perlbrew/perls/perl-5.20.0/lib/5.20.0/darwin-2level/perllocal.pod
# Checking for
/var/folders/5s/sk58jrwj7jj73phc9lcx9nh8gn/T/cgOOrG5f45/Users/sno/perl5/perlbrew/perls/perl-5.20.0/etc/fsd-install.json
ok 5 - Installed: t/etc/fsd-install.json
1..5
So neither the warning goes away nor existing constants are overwritten.
Right. There seem to be two layers of verification, I had missed the second
one. That is a bummer. There should be a way around this, I just need to find
it.
Would be cool, thanks!
For some reason File::ConfigDir::Install doesn't just override postamble,
it modifies the install_*_* instructions ...
...BigHelper (mohawk pointed to that) does something similar.
I think there is more a hook like
https://metacpan.org/pod/Class::Method::Modifiers#around-method-s-sub needed
for each of overloaded function ...
Right. There really ought to be a ExtUtils::MakeMaker::Extensible layer to
make this all easier.
I can care for this (with some wise words from #toolchain).
What can be a reasonable approach for providing the around?
Using Class::Method::Modifiers and suggest bundling for distributions for
ancient environments?
As far as I see it has only core dependencies...
inc::latest does a great job for bundling. It does exactly what I want to reach
with ExtUtils::BundleMaker.
I tried it in LMU 0.400_010 - this sounds being a reasonable approach for
distributions using ExtUtils::MakeMaker::Extensible.
Cheers
--
Jens Rehsack
rehs...@gmail.com
Integrating C::AC into MakeMaker/MB
Hi, I run into some trouble integrating some right linker flags to a Makefile.PL - insane warnings from EU::MM is an offenseless artifact, deleted flags is next escalation. I don't want discuss about utility and futility of the misplaced parameter approvals (EU::MM is a Makefile generator, not a configuration tester), I want to discuss a reasonable approach to pass check results into Makefile without doing the mistakes of Module::Install again. My naive approach was passing EXTRALIBS and LDLOADLIBS instead of LIBS (https://github.com/i-scream/Unix-Statgrab/blob/master/Makefile.PL#L102-105) - I grabbed the idea from Net-SSLeay ... But Dave objects (https://github.com/autarch/File-LibMagic/pull/3) and beside being always right I have to concede a point to Dave regarding warnings confuse end-users. I played a bit with MakeMaker extensions hacking https://metacpan.org/pod/File::ConfigDir::Install and mohawk pointed me to https://metacpan.org/pod/ExtUtils::MakeMaker::BigHelper ... I know, all those MM extensions (ShareDir::Install ...) will not play well together. What should be a reasonable way out - having a pluggable API for all those extensions? Cheers -- Jens Rehsack rehs...@gmail.com
Re: Integrating C::AC into MakeMaker/MB
Am 01.12.2014 um 17:59 schrieb Leon Timmermans faw...@gmail.com:
On Mon, Dec 1, 2014 at 11:48 AM, Jens Rehsack rehs...@gmail.com wrote:
Hi,
I run into some trouble integrating some right linker flags to a Makefile.PL
- insane warnings from EU::MM is an offenseless artifact, deleted flags is
next escalation.
I don't want discuss about utility and futility of the misplaced parameter
approvals (EU::MM is a Makefile generator, not a configuration tester), I
want to discuss a reasonable approach to pass check results into Makefile
without doing the mistakes of Module::Install again.
My naive approach was passing EXTRALIBS and LDLOADLIBS instead of LIBS
(https://github.com/i-scream/Unix-Statgrab/blob/master/Makefile.PL#L102-105)
- I grabbed the idea from Net-SSLeay ...
But Dave objects (https://github.com/autarch/File-LibMagic/pull/3) and beside
being always right I have to concede a point to Dave regarding warnings
confuse end-users.
I think you can work around the warning using a CONFIGURE callback:
WriteMakefile(
CONFIGURE = sub {
return {
EXTRALIBS = ...,
LDLOADLIBS = ...,
}
},
);
Seems reasonable - but as you know in not to distant future, they shall
also override CC, CCLD, ... (using ExtUtils::Builder or alike, instead
of plain cc).
Does the return hash of this callback overrides all EU::MM constants?
Is there a minimum version of EU::MM for this CONFIGURE callback?
I played a bit with MakeMaker extensions hacking
https://metacpan.org/pod/File::ConfigDir::Install and mohawk pointed me to
https://metacpan.org/pod/ExtUtils::MakeMaker::BigHelper ...
I know, all those MM extensions (ShareDir::Install ...) will not play well
together.
What should be a reasonable way out - having a pluggable API for all those
extensions?
They can be made to cooperate by not exporting the postambles to MY::, but
instead glue them together something like this:
my @extensions = (...);
load($_) for @extensions
my @methods = map { my $method = $extension . ::postamble } @extensions;
sub MY::postamble {
my ($makemaker, %args) = @_;
return join \n\n, map { $makemaker-$_(%args) } @methods;
}
For some reason File::ConfigDir::Install doesn't just override postamble,
it modifies the install_*_* instructions ...
...BigHelper (mohawk pointed to that) does something similar.
Cheers
--
Jens Rehsack
rehs...@gmail.com
configure_requires ...
Aloah, while playing around with https://github.com/rehsack/File-ConfigDir-Install (attention: surreptitious advertising) and having the missing out-of-the-box configure_requires before 5.14 limitation - could there be a way to hack around that mis-using Makefile's config-target? Just an idea - unproved and not reflected at all ... Cheers -- Jens Rehsack rehs...@gmail.com
Re: configure_requires ...
Same as I wanted to reach using EU::BundeMaker I hope I get most open stuff out before Berlin, so I can ... kind of motivate you there ;) Meanwhile proving CPAN::AutoINC and CloudPAN. /Jens Am 24.11.2014 um 02:39 schrieb David Golden x...@xdg.me: Something like CPAN::AutoINC or CloudPAN might be a way to bootstrap, but you're in uncharted territory. I'd be much more likely to bundle stuff in inc. I'm planning to split inc::latest out into a separate distribution and experiment with it for this kind of thing. (inc::latest gives you what's bundled in inc unless you have a higher version already installed.) David On Sun, Nov 23, 2014 at 10:54 AM, Jens Rehsack rehs...@gmail.com wrote: Aloah, while playing around with https://github.com/rehsack/File-ConfigDir-Install (attention: surreptitious advertising) and having the missing out-of-the-box configure_requires before 5.14 limitation - could there be a way to hack around that mis-using Makefile's config-target? Just an idea - unproved and not reflected at all ... Cheers -- Jens Rehsack rehs...@gmail.com -- David Golden x...@xdg.me Twitter/IRC: @xdg -- Jens Rehsack rehs...@gmail.com
Re: Lancaster Consensus, deal with PUREPERL_ONLY=0
Am 04.06.2014 um 07:00 schrieb Jens Rehsack rehs...@gmail.com:
Am 04.06.2014 um 04:32 schrieb David Golden x...@xdg.me:
On Tue, Jun 3, 2014 at 1:35 AM, Jens Rehsack rehs...@gmail.com wrote:
1) compiler cannot create executables
2) compiler works, but no perl headers
3) compiler does, but shared library building fails (that is fragile and
minor modifications at the system causes that process to fail)
These three would all fail to make, which would abort installation.
4) As you say: https://rt.cpan.org/Ticket/Display.html?id=75672
Oooh! Excellent example.
make succeeds and make test could fall back to PP when dynaloading fails.
I wonder if there's a way to be clever about this such that under
PUREPERL_ONLY, make never compiles the extension, and then the main
module doesn't just try bootstrap inside eval{} but actually checks to
see if the extension is in @INC. If so, bootstrap it or die; if not,
fall back to pure Perl.
talked yesterday with riba about that in deeper detail.
We decided to do as (probably) suggested by you and
sub legacy_exists { die bogus legacy XS if the extension is in @INC; return
false }
autoconf-check_pp_wanted and return legacy_exists;
autoconf-have_compiler or return legacy_exists;
autoconf-check_perl_api or die;
if( autoconf-extensive_testing ) {
autoconf-check_perl_extension_links or die;
autoconf-check_perl_extension_loads or die;
}
return ok
http://www.cpantesters.org/cpan/report/a25a36da-ea1d-11e3-9cf0-a01f06268b4b
is also an excellent example.
Regarding if the extension is in @INC (have separate installed XS module)
needs a migration plan for LMU, P::U etc.
This is the final solution and we had several ideas yesterday for a migration
plan - but wasn't complete.
Here is the commit for that:
https://github.com/rehsack/Config-AutoConf/commit/e8a14d079995ea519c3aebc698994ea5964bbf70
If there're no objections, I fire a release with that change (and the one which
skips compile tests for bogus environments as Nigel Hone has ...)
Cheers
--
Jens Rehsack
rehs...@gmail.com
Re: RFC Consensus on Network testing ENV?
Am 11.06.2014 um 19:08 schrieb David Golden x...@xdg.me: On Wed, Jun 11, 2014 at 11:52 AM, Kent Fredric kentfred...@gmail.com wrote: Has the user in question granted permission to use the internet. I disagree with the premise that one needs to ask. Users are already running arbitrary Perl code and must take responsibility for anything that it might do and not run it if it does something they don't want it to do. The only thing that interests me is avoiding hassling people with failures in cases that have no possibility of success, e.g. connecting to a host on the Internet when the Internet is fire-walled. That's a question of capability, not permission. I think there're setups where smoke tests run in a private. not routed network segment. While this is uncommon, probably an envvar is the right approach, but it should be one like LOCALTESTS_ONLY instead of NETWORK_IS_AVAILABLE. This allows smokers to disable unwanted network tests. How does that sound? (Maybe I don't understand the concern correctly) Cheers -- Jens Rehsack rehs...@gmail.com
Re: Lancaster Consensus, deal with PUREPERL_ONLY=0
Am 04.06.2014 um 04:32 schrieb David Golden x...@xdg.me:
On Tue, Jun 3, 2014 at 1:35 AM, Jens Rehsack rehs...@gmail.com wrote:
1) compiler cannot create executables
2) compiler works, but no perl headers
3) compiler does, but shared library building fails (that is fragile and
minor modifications at the system causes that process to fail)
These three would all fail to make, which would abort installation.
4) As you say: https://rt.cpan.org/Ticket/Display.html?id=75672
Oooh! Excellent example.
make succeeds and make test could fall back to PP when dynaloading fails.
I wonder if there's a way to be clever about this such that under
PUREPERL_ONLY, make never compiles the extension, and then the main
module doesn't just try bootstrap inside eval{} but actually checks to
see if the extension is in @INC. If so, bootstrap it or die; if not,
fall back to pure Perl.
talked yesterday with riba about that in deeper detail.
We decided to do as (probably) suggested by you and
sub legacy_exists { die bogus legacy XS if the extension is in @INC; return
false }
autoconf-check_pp_wanted and return legacy_exists;
autoconf-have_compiler or return legacy_exists;
autoconf-check_perl_api or die;
if( autoconf-extensive_testing ) {
autoconf-check_perl_extension_links or die;
autoconf-check_perl_extension_loads or die;
}
return ok
http://www.cpantesters.org/cpan/report/a25a36da-ea1d-11e3-9cf0-a01f06268b4b is
also an excellent example.
Regarding if the extension is in @INC (have separate installed XS module)
needs a migration plan for LMU, P::U etc.
This is the final solution and we had several ideas yesterday for a migration
plan - but wasn't complete.
Cheers
--
Jens Rehsack
rehs...@gmail.com
Re: Lancaster Consensus, deal with PUREPERL_ONLY=0
Am 02.06.2014 um 13:34 schrieb David Golden x...@xdg.me: On Mon, Jun 2, 2014 at 7:28 AM, Jens Rehsack rehs...@gmail.com wrote: Others (eg. packagers) have always a compiler and want benefit from XS when available and what is more important: if the DEVELOPER MODE FLAGS IS ON, they want to have a -Werror behavior even for I enabled foo and it doesn't appear. I don't understand what you mean by this. http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html It's the widest know of those flags - GNU autotools provide such a one, too. xlc names it -qhalt=severity ... Lot's of tools provide switches which exit when something doesn't do as wanted (if a specific behavior is intended). I'm fine with Jens' distribution have a non-standard switch, but I would prefer a Toolchain community favors that knob to be used. In Lancaster, we considered having both a give me PP option *and* a give me XS option and the group decided it was less confusing to have just one. I didn't had the user control author mind situation. I evolved by implementing (both sides - provide CPAN distributions and use/package them). Here's how I would do it: (a) if the PP option is there, give them PP (b) if the PP option is missing/false, check if there is a compiler (c) if there is a compiler, give them XS or give them death (d) if there isn't a compiler, give them PP If for (c) that means running tests under some XS-only flag of your own, that's fine with me. (b)-(d) shall die (or exit 0 in Makefile.PL) when XS-force flag is set. I currently prove: a) what is wanted (tri-state: PP-only, XS-only, check) pp-b) do just pp b) check for sane xs (perl.h, xsub.h, perl-api, ...) xs-c) (b) or bail-out check-c) (b) or goto (pp-b) d) compile pp Is that somehow clear? But ... that brings me to another point of view. Take Unix::Statgrab, File::LibMagic or BSD::Resource as example - they won't work without XS either. Shall they generally bail-out when PUREPERL_ONLY=1 is set? Cheers -- Jens Rehsack rehs...@gmail.com
Re: Lancaster Consensus, deal with PUREPERL_ONLY=0
Am 02.06.2014 um 16:05 schrieb David Golden x...@xdg.me: On Mon, Jun 2, 2014 at 9:22 AM, Jens Rehsack rehs...@gmail.com wrote: Web-Search for CPAN Testers magic strings doesn't provide suitable results - is there a list of those magic results? http://wiki.cpantesters.org/wiki/CPANAuthorNotes This can help for Sys::Filesystem - good to know. I'll re-check how that behaves against that description. If I would know what is expected, I will make Config::AutoConf behave. Devel::CheckLib doesn't work at all - but I don't want to send pull requests using C::AC until I'm sure that C::AC doesn't introduce more pitfalls than it solves ;) Here's what I think is important to understand: * PASS/FAIL reports are only supposed to happen if tests actually run (e.g. make test, etc.). These should not be sent if a cpan reporting client can detect that perl prereqs are missing. * UNKNOWN reports are supposed to happen when the dist never reaches the test stage (e.g. Makefile.PL or make fails) or if there are no test files to run. This means I don't know if your tests pass or fail because I never got that far * NA reports are supposed to happen when there is no possible way for tests to ever succeed. Generally this is for platform/OS issues, like Win32::Job will never succeed on Unix, or something that needs threads will never run on a non-threaded perl. I've seen it used and used it myself for situations where some configuration issue prevents success -- e.g. you're running on OpenBSD and your perl is neither threaded or single-threaded-but-linking-libpthead. * exit 0 from Makefile.PL has a coincidentally useful behavior that CPAN Testers exploits. The CPAN clients happened to all check for Makefile being created even if Makefile.PL returned exit code zero and bailed out if it didn't exist. That allowed a way to let Makefile.PL abort without triggering a CPAN Testers report message. This turned out to be really useful for non-perl dependencies (e.g. compiler, C libraries, external program, etc.) That's what I knew and how C::AC behaves. So everything is cool :D Additionally - if one needs - there is a config.log containing all made tests and for those who fail the complete scenario with call and failure output. Cheers -- Jens Rehsack rehs...@gmail.com
Re: Lancaster Consensus, deal with PUREPERL_ONLY=0
Am 03.06.2014 um 01:28 schrieb Aristotle Pagaltzis pagalt...@gmx.de: * Karen Etheridge p...@froods.org [2014-06-02 01:30]: I do not see any gain in specifying give me XS or give me death. This I find easy to see, at least if we are talking of the general case: If I have my system set up to support XS then I want it to use XS, and if for some reason it can’t, then there is a bug somewhere that needs to be fixed, so I do *not* want it to silently give me the PP version and carry on, but to fall down and die screaming so I’ll find out. Precisely. However, I am unsure of the context of the discussion. I simply detected that we (p5) don't cover that situation, we always fallback to PP. The above reasoning is applicable and important mostly when it comes to production deployments: I never want my servers trying to limp on with a CPU- and/or memory-hungry setup that will only reveal itself as such in monitoring data. Production deployment is somehow similar to packaging - packaging is one step in deployment (even tar xjf ... is packaging or rsync a prepared directory). And then it comes - do the farm has the same arch and is XS possible and wanted, does your package process gives you the ability to distinguish between archs or is your process one blob to rule them all - than is FatPacking your hammer and XS is unwanted. But: Do the folks at CERN really FatPacking? AFAIK (I talk here and there in train to guys having experiments there) no. But maybe the discussion is about some other scenario in which the given reasoning is inapplicable? Since I don’t know, the above use case may be neither here nor there. Depending on one's background, usecases sounds ridiculous. As pkgsrc maintainer (16+ platforms 30+ architectures supported) I do not understand the existence of fat packer at all. pbulk+pkgin is easier to deal with ... But I accept the usecase - even when I don't understand it. Cheers -- Jens Rehsack rehs...@gmail.com
Re: Lancaster Consensus, deal with PUREPERL_ONLY=0
Am 03.06.2014 um 01:42 schrieb David Golden x...@xdg.me: On Mon, Jun 2, 2014 at 7:28 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote: If I have my system set up to support XS then I want it to use XS, and if for some reason it can’t, then there is a bug somewhere that needs to be fixed, so I do *not* want it to silently give me the PP version and carry on, but to fall down and die screaming so I’ll find out. I've been trying to think of how that could happen and so far all I can come up with is this scenario: * XS bits compile successfully, but the shared object croaks during bootstrap, and the calling module traps the bootstrap error and falls back to PP There're several scenarios causing XS builds to fail: 1) compiler cannot create executables * invalid cflags configured (see http://www.cpantesters.org/cpan/report/a25a36da-ea1d-11e3-9cf0-a01f06268b4b for an example) * beta compiler test (sunpro 12.4 on linux fails loading libdwarf) * cc installed, but as missing 2) compiler works, but no perl headers 3) compiler does, but shared library building fails (that is fragile and minor modifications at the system causes that process to fail) 4) As you say: https://rt.cpan.org/Ticket/Display.html?id=75672 I think currently we don't cross-compile (handy market would make me want to change that), which allows tests for 4, but until 3 we can always test. 4 only when we don't cross-compile. And what does I prepared my system to support XS mean? I installed a compiler or I installed precisely the same compiler/binutils used to build perl? I think, there should be a flag the user to be able to set to express the opinion the system is prepared for XS - not any magic detection. Users word counts. Cheers -- Jens Rehsack rehs...@gmail.com
Re: Lancaster Consensus, deal with PUREPERL_ONLY=0
Am 01.06.2014 um 15:03 schrieb David Golden x...@xdg.me: The only thing specified in the lancaster consensus is what must happen if that command-line argument is true. I think making a distinction between 0 and undefined will be surprising to people and I would recommend against it. Given this point - how can we give people an instrument to force XS and fail if it's not available? On Sun, Jun 1, 2014 at 7:19 AM, Jens Rehsack rehs...@gmail.com wrote: Hi, I implemented the interpretation of PUREPERL_ONLY in C::AC as: equals 1 - don't XS (even don't prove) equals 0 - don't PP only (force XS, fail if cannot be proved) undefined - XS/PP depends on prove Ribasushi hinted to verify my interpretation to ask on ML. So what do others think - how should PUREPERL_ONLY=0 being interpreted? Cheers -- Jens Rehsack rehs...@gmail.com
Re: Lancaster Consensus, deal with PUREPERL_ONLY=0
Am 01.06.2014 um 20:09 schrieb Peter Rabbitson rab...@rabbit.us: On Sun, Jun 01, 2014 at 05:59:16PM +0200, Jens Rehsack wrote: Am 01.06.2014 um 15:03 schrieb David Golden x...@xdg.me: The only thing specified in the lancaster consensus is what must happen if that command-line argument is true. I think making a distinction between 0 and undefined will be surprising to people and I would recommend against it. Given this point - how can we give people an instrument to force XS and fail if it's not available? As I mentioned before - you create a separate ::XS distribution, against which the outliers declare dependencies. In general forcing XS when PP is available is *always* *invairably* the wrong approach (which is why they are called outliers above ;) The user must always have a way to enforce or fail. And not every distribution can be split into 2. So please forget the cases where it's possible to split and let's come back to the question: How can we enable the user/packager to make a clear choice? Cheers -- Jens Rehsack rehs...@gmail.com
Re: For P::PT - ExtUtils::XBuilder
On 19.11.12 19:43, Leon Timmermans wrote: On Sun, Nov 18, 2012 at 8:41 PM, Jens Rehsack rehs...@gmail.com wrote: long time ago I wanted a ExtUtils::CBuilder successor. Leon started such a one, but it hasn't the features I needed for e.g. Proc::ProcessTable or Net::Radio::Location::SUPL::Test - so I started an own one - see http://repo.or.cz/w/ExtUtils-XBuilder.git I'm still working on that. I actually was planning to post an announcement one of these days. I think your goals are a lot more high-level than mine, to me it makes more sense to build your library on top of mine. Well, I need control over the invoked executables and flags for specific languages - especially for integrating it into Config::AutoConf and do other multi-compile stages (as Net::Radio::Location::SUPL::Test requires first ASN.1 - C compile stage, then C - object, then link into *.so). I looked into EU::B and I didn't see that I get full control for those requirements, but I might be pebcak and not a limitation of EU::B ;) Now it's time to integrate that solution into P::PT - but I need a better CBuilder for it. I can imagine that. EU::CB is a What? Was the word took out by the dis filter ;) -- Jens Rehsack
Re: Introducing ExtUtils::Builder, a new compilation and linking toolkit
On 20.11.12 02:11, Leon Timmermans wrote: Hi all, As a few of you may already know, I've been working on a new compilation and linking toolkit, called ExtUtils::Builder. It's intended as a replacement for ExtUtils::CBuilder. ExtUtils::CBuilder has a number of issues that I'm running into: 1) The only thing it does reliably is creating loadable-objects for perl. On some platforms it doesn't do shared libraries or executables, and static libraries aren't in the picture anywhere. It also insists on linking to perl's dependencies on some platforms. This greatly reduces the usefulness of the library. 2) It can't plan ahead, it can only perform the compiling/linking. This is a problem if you for example want to embed it into a Makefile, but also if you want to modify the commands before running. 3) It's very inflexible in its options. It has for example an extra_linker_flags option, but it has a fixed position. Since linker flags tend to be very order dependent, this means it's often the wrong position. Likewise you can't choose it's exportation method, it always does some platform-specific thing (either exporting all or exporting a select set of symbols). These issues all boil down to «it does exactly what is was designed to do, don't expect anything more». It goes so deep that a redesign from scratch is inevitable to me. I'm dealing with these issues by using a radically different design in EU:B. I'm using builder roles for the compiler and linker that allow you to specify what you'd like them to do. The classes implementing these roles are essentially drivers for various compilers/linkers. These classes build action objects, that can either be executed, or turned into a command to be run (e.g. [qw/cc -o foo.o -c foo.c -Iheaders/]). There's a separate class that inspects perl's configuration uses that to instantiate the known compiler/linker with the right options, but the rest of the framework can be used independently. It's currently in a fairly early state (and rather lacking documentation); it's known to work on Linux, HP-UX and OS X but it is still being ported to other platforms (there is some code for Windows already). I can very much use some platform specialists for help there. Patches and comments are very welcome. The code is at https://github.com/Leont/extutils-builder This is really cool stuff for the thing it's designed for. I'm pretty sure, it will satisfy a hugh amount of developers. Thanks, Leon -- Jens Rehsack
For P::PT - ExtUtils::XBuilder
Hi, long time ago I wanted a ExtUtils::CBuilder successor. Leon started such a one, but it hasn't the features I needed for e.g. Proc::ProcessTable or Net::Radio::Location::SUPL::Test - so I started an own one - see http://repo.or.cz/w/ExtUtils-XBuilder.git Currently I have to figure out how I can avoid retesting same things and whether I shall put the toolchain class to @XBuilder::ISA or relying on the Flyweight pattern. But I wanted you stay up-to-date. PS: For reasons why Proc::ProcessTable took so long time to finish, is that I do it in spare free time - and there're other Modules need attention, too. Beside the known ones - DBI and SQL::Statement (plus DBD::CSV, ...), there're - DBIx::Log4Perl and RT#79282 (== Log::Any is very expensive, 'cause it expands Log-Strings regardless the log-level is enabled or not) - MooseX::App::Cmd / MooseX::ConfigFromFile / Getopt::Long::Descriptive and Getopt::Long (or any replacement, 'cause of RT#79912, RT#79746 and https://github.com/mjgardner/moosex-app-cmd/issues/2) Anyone who is willing to help on ExtUtils::XBuilder is very welcome, but if not - please don't touch Proc::ProcessTable unless you understand the entire impact (see src/libstatgrab/process_stats.c in http://www.netbsd.org/~sno/smart-snmpd/libstatgrab-0.17.20120906.01.tar.gz for details). Grabbing process stats in a possible multi-threaded environment on so many different architectures isn't a trivial task and I figured out a solution for most Unices and free systems. Now it's time to integrate that solution into P::PT - but I need a better CBuilder for it. Best regards, Jens -- Jens Rehsack
