|
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 28 August 2016. |
|||
|
06:41
domidumont joined
06:46
domidumont joined
08:19
leont joined
10:56
leont joined
11:46
tbrowder joined
|
|||
| tbrowder | hi, anyone here? | 11:47 | |
| questions about developing a module for distribution: | 11:49 | ||
| DrForr | Here, but still recovering from YAPC :) | ||
| tbrowder | 1. how does one identify the files and dirs to be installed? META6? Build.pm? | 11:50 | |
| I hear good things about YAPC! | |||
| 2. where is definitive source for the contents of the META6 file? | 11:51 | ||
| moritz | META6 | 11:52 | |
| docs.perl6.org/language/modules#Di...ng_Modules has some docs. It' probably not "the definitive source", but the best I know of | 11:53 | ||
| tbrowder | yes, that doesn't help a lot; jnthn's meta6 test talks about allowable and not allowable but it's not clear to me yet how to find the detailed specification (but i haven't checked synopses, either) | 11:56 | |
| i just asked jnthn on #perl6 | 11:57 | ||
|
13:37
domidumont joined
|
|||
| ugexe | You can't identify which files and dirs to install | 13:54 | |
| you can identify which modules to install via provides. you can identify which resources via resources. Anything in bin/ gets installed | |||
| S22 is the most definite source on META6 format but even that isn't set in stone | 13:55 | ||
|
14:21
tadzik joined
14:30
domidumont joined
|
|||
| mst | tadzik: hrm. now I'm wondering how many people using rakudobrew are, at this point, using it for anything except "installing and upgrading one moarvm based rakudo" | 15:35 | |
| tadzik | infinitesimal amounts, I think | 15:36 | |
| ugexe | i use rakudobrew to manage the various releases. so i have 2016.01, 2016.02, etc | ||
| moritz | mst: I use it for upgrading, and having the option to roll back | 15:43 | |
| mst | moritz: yeah | ||
| moritz | but it was more relevant back when we had several working and interesting backends | 15:44 | |
| mst | I do hope the JVM backend comes back eventually | ||
| but what I'm mostly thinking is "for people who don't already have a local::lib, what's the simplest thing we could provide that would be useful" | |||
|
16:52
lizmat joined
|
|||
| nine | For building Inline::Perl5 we'd need $*VM.config variables, mapping logical library names to physical ones ($*VM.platform-library-name) and a way to capture output of command line tools into variables. | 17:21 | |
| Kind of like: "build": {"makefile-variables": {"p5helper": {"library": "p5helper"}, "perlopts": {"run": "perl -MExtUtils::Embed -e ccopts -e ldopts"}}} | 17:24 | ||
| "library" would expand the name using: 'resources'.IO.child('libraries').child($*VM.platform-library-name($value.IO)) | 17:25 | ||
| "run" just run($value, :out).out.lines.join('') | |||
|
17:37
domidumont joined
|
|||
| nine | Aaaand that works | 17:54 | |
| I guess we should ship this code as Distribution::Builder or something like that | 17:56 | ||
| kudo/raccoon: b5a0394 | niner++ | / (3 files): First steps towards a declarative build system for modules |
18:12 | ||
| kudo/raccoon: 979215d | niner++ | tools/ (4 files): Install raccoon formerly known as install-dist.pl |
|||
| ugexe, mst: ^^^ | |||
| mst | oooo | 18:51 | |
| nine | Actually, since all native libraries will already be listed in resources, we could just as well create Makefile variables for them automatically without repeating them in the build section | 19:07 | |
| ugexe | github.com/rakudo/rakudo/commit/b5...9d3386bR48 # Doesnt this add a dependency on perl 5? | 19:44 | |
| nine | ugexe: oops...that should be run($value).out.lines.join('') | 19:47 | |
| pushed fixed commits | 19:48 | ||
| github.com/rakudo/rakudo/commit/ac...fdb4adaef3 | 19:49 | ||
| [Coke] | ... did you just force push? | 19:50 | |
| nine | yes | ||
| [Coke] | I was under the impression that we were supposed to never. ever. do that. | 19:51 | |
| maybe that's just for 'nom', but I thought it was more generic. | 19:52 | ||
| nine | It's for branches that others work on which I'm quite sure is not yet the case here. | 19:56 | |
| mst | [Coke]: if it's your own branch and nobody else is going to have a problem, better to keep history clean | 20:05 | |
| generally, I go for "don't force push unless there are no other people working on the branch who would have problems with this" | |||
| (I often force push on shared branches, but only when working with people who also prefer the trade-offs) | 20:06 | ||
| [Coke] | sure, all fine. we should write down the policy. | 20:11 | |
| mst | my version mostly boils down to "screw dogma, just don't shit on other people" | ||
| [Coke] | (in the same doc where we try to apologize for using 'nom' instead of 'master') | ||
| mst: sure, that's fine. we should write that down | |||
| mst | sure, I just don't think my phrasing is the correct one to put into the repo ;) | 20:12 | |
|
20:40
leont joined
21:42
leont joined
22:09
leont joined
23:00
leont joined
|
|||