Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
Set by moderator on 6 May 2016.
04:40 ribasushi joined
MadcapJake ugexe: `zef build` doesn't seem to run my Build.pm file github.com/Perl6-Noise-Gang/Audio-...r/Build.pm 05:11
gotta get some sleep though 05:12
05:39 domidumont joined 05:44 domidumont joined 06:10 domidumont joined
nine_ Random thought on Build.pm: we should really aim for a systemd like declarative way to specify the build process with hooks for custom code that users are really discouraged from using and which should only be meant for extreme situations. 06:37
moritz +Inf 07:06
07:21 cognominal joined 07:37 cognominal joined 13:06 sufrostico joined
ugexe ive been saying for for 3 years 15:26
mst Build.pm is an utterly terrible idea, but not the most proximate yak as yet, I suspect 15:27
leont's build-graph stuff looks interesting
what we could really do with is an audit of what people are actually using Build.pm *for* to figure out what the feature set needs to be
nine_: I'd like our build process to be deterministic though, so systemd isn't the ideal thing to compare it to :) 15:28
ugexe almost all of them are for running make, or aborting the install for some reason
mst \\o/
/o\\ 15:29
*sob*
MadcapJake My goal was to generate Perl 6 files when a user installs the module 15:31
ugexe s22 even mentions how to declare it: leaf nodes that are hashes which CURs are meant to ignore and builders/packagers can interpret and do what they need 15:32
MadcapJake So that I could change the bindings according to architecture, OS 15:33
if that's not the preferred route for accomplishing what I described, then what is? 15:34
ugexe MadcapJake: i'll check your build... fwiw you can do ZEF_BUILDPM_DEBUG=1 to get the output 15:39
MadcapJake ok well I just took out the Panda::Build stuff and there's a few kinks that I haven't ironed out yet. I'll get it working as a regular script then plug the builder interface back in 15:40
ugexe but you certainly dont need to depend on panda for this
MadcapJake yeah? how do I do it then? just a build sub? 15:41
or will zef just run the script and it can do it's thing
ugexe github.com/titsuki/p6-Term-Readsec...fb167545bc
that shows how to turn a build.pm that requires panda into one that does not 15:42
basically you remove the is Panda::Builder and add the `method isa`
MadcapJake ok neat thanks! just a Build class with a build method then eh? (the rest I assume is LibraryMake stuff, right?)
ugexe thats only for compatability with panda, zef does not need it
yeah, but you need the method isa to work with panda this way 15:43
MadcapJake gotcha
MadcapJake notes that he'll need to do that LibraryMake stuff too 15:44
ugexe first thing though, the META.info has a comma after the last item 15:46
then it looks like you call transpile and pass it Str args, but calls `.child` on them 15:48
s/.child/.IO.child/ and it builds 15:49
tadzik I may just remove that bit from old panda so you don't need to torment yourself with isa 15:50
nine_ ++tadzik 15:51
tadzik there may have been one at some point, when Build was actually meaningful, but these days there is no reason for it to be there
or so I think 15:54
I know p6doc uses some actually panda-specific features, but iirc it's just Installer 15:55
I'd be as happy as everyone to see Build.pm gone, fwiw :)
requirement gone as of now 15:56
no, I didn't bump the version number ;)
MadcapJake why all the Build.pm hate in here? :P 15:58
mst because it's complete crap?
MadcapJake what is? 15:59
tadzik (hey, sorry for making this whole module thing work for the last 5 years... :P)
mst it's a classic example of "we've no idea what we should be doing here, so let's try something" ossifying into a de-facto standard without anybody going back and actually designing it
tadzik: hey, if I'd tried to achieve the same thing at the same time, my answer would've been just as crap
you did fine. but it's still crap.
MadcapJake I don't see anything wrong with having essentially a post-download script that lets module authors generate files or install libraries 16:00
tadzik Build.pm is as much of a PITA to me now as to everyone else (or more so), since it makes shipping a new, incompatible panda version a massive clusterfuck
mst MadcapJake: yes, but it's rather more than that
tadzik (for modules that actually depend on panda now)
mst an actual *just* a post-download script would be a much nicer thing
MadcapJake mst: how so?
what makes it more than that?
tadzik my reasoning, as far as I remember, was "Perl 5 has that Build.PL thing, I'll just do something similar but make it not spawn a subprocess because that's costly as fuck" 16:01
ah, I know why inheritance now
so you can have your own Build.pm do a callsame at the end, or something? I guess? Maybe? :)
nah, that'd just recurse indefinitely 16:02
*shrug*
nine_ MadcapJake: #1 Build.pm is panda-specific even if there are hacks around that. #2 panda will load all Build.pm files into the same process, overwriting the same class Build every time. I'm not even sure that's supposed to work...
ugexe in addition to that, when you smoke test and use Build.pm in the same process as the package manager, you make it possible for other modules to cause build failures for other modules by breaking the packager 16:03
nine_ MadcapJake: #3 you cannot reason at all about what a given dist will install if it contains a Build.pm. For all you know it could replace your distribution with something downloaded from elsewhere. IOW you cannot statically analyze it at all.
tadzik heh, I think there are modules who do exactly that :P 16:05
MadcapJake While #1 and #2 are implementation-dependent, I can definitely see now how #3 could be problematic.
jdv79 #3 sucks pretty hard
tadzik then again, if they need it they may as well do it in BEGIN { } time or whatever
ugexe a solution to that is mentioned in S22 under %?RESOURCES `"resources" : [ 'libraries' : { 'blah.so' : build-time }` 16:06
jdv79 do we have ability to spec the arch yet? i think that was a/the major issue there; specifically. 16:07
tadzik there's a module somewhere that grabs .so or .dll from the internet in build-time, isn't that gtk::simple?
MadcapJake jdv79: yeah that's what I'm wondering, I see that generating on install is dangerous but then how can I hinge on architecture wrt nativecall types?
tadzik yep: github.com/perl6/gtk-simple/blob/m...r/Build.pm 16:08
jdv79 but does that handle other archs? pretty sure that's not the full breadth of reasonable possibilities.
tadzik "dangerous" is a little bit silly when you literally download code to run it on your computer
you'll never be safe from shit in modules you download 16:09
nine_ MadcapJake: the idea is that the installer can do whatever you need and there is a declarative way to tell it to do so. Preferably this infrastructure is even shared between installers.
MadcapJake: a package repository or database like modules.perl6.org will then be able to give detailed analysis (like "which module contains a libp5helper.so?") without even having to be able to run Perl 6 code 16:11
MadcapJake so by declarative you mean like S22's %?RESOURCES as ugexe mentioned?
nine_ yes 16:12
MadcapJake I'm still left wondering how I would handle int32/int64 in my nativecall bindings 16:13
nine_ MadcapJake: how exactly do you do that right now? 16:15
MadcapJake I don't! :P I wrote a Build.pm that parses header files and generates Perl 6 subs (like gptrixie) and I was planning on just using ternaries for arch/os related stuff 16:16
but then that would mean that all of the nativecall stuff would not be in the gh repo nor available for static analysis until after Build.pm is run (which will probably be at least half of the code) 16:19
nine_ Inline::Perl5 does it at BEGIN time: sub p5_size_of_iv() is native($p5helper) returns size_t { ... }; BEGIN my constant IV = p5_size_of_iv() == 8 ?? int64 !! int32; 16:21
MadcapJake I could generate both, do it on my end and thus include it in the gh repo, and then in my non-arch-dependent code, use the appropriate nativecall "backend". but this would mean users are installing lots of extra junk, I suppose that's preferable though, perhaps?
nine_: cool! what's the p5_size_of_iv function from? 16:24
nine_ p5helper.c that comes with Inline::Perl5. Of course that means that I have to build a shared library as part of the build process... 16:25
You could however parse those headers instead
16:30 domidumont joined 17:13 hankache joined 17:29 Kassandry joined 19:43 sufrostico joined 21:25 sufrostico joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!