|
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 14 February 2016. |
|||
|
07:04
japhb joined,
llfourn joined,
MadcapJake joined,
autarch joined
07:17
FROGGS joined
12:24
leont joined
13:06
sufrostico joined
14:27
sufrostico joined
15:19
leont joined
17:17
hankache joined
17:45
Kassandry joined
18:06
sufrostico joined
18:33
FROGGS joined
|
|||
| nine | I wonder how the replacement for Build.pm should look like. Now that require's fixed in rakudo, I cannot even get the hack panda's using to work again. | 19:31 | |
|
19:34
sufrostico joined,
sufrosti1o joined
|
|||
| tony-o_ | isn't the replacement the hooks? | 19:50 | |
| nine | which hooks? | 19:55 | |
| ugexe | i think he means the replacement is as simple as the very lacking documentation on special directory `hooks/`. To summarize: hooks/ would contain executable perl6 code that would be executed at various stages. this is how zef currently treats Build.pm (as an executable script) | 20:06 | |
| the way panda does it currently has no separation of itself and Build, so whacky native call errors during Build can cause havok on a panda smoke test | 20:07 | ||
| but by taking the simple route of scripts in hooks/ (maybe declaring them in the meta) is it easily extends to any part of the install process (parts CURI wouldnt care about, but packagers would) | 20:08 | ||
| and they can be created/executed without any dependencies | 20:09 | ||
| this solution requires 2 things to be thought out first: 1. names hooks (including -fixes like pre/post/ok/failure i.e. a pre-Build hook, post-Build hook) 2. What information gets passed to each hook, and how (usually an ENV var but whatever works) | 20:11 | ||
| github.com/ugexe/zef/tree/ec1b99f4...9251/hooks is a very basic implementation. but it may be better to declare them in META itself so you can name your files anything, and just attach a 'build-time' tag (see s22 %?RESOURCES) | 20:17 | ||
|
20:17
llfourn joined
|
|||
| ugexe | In the mean time, the following works for executing Build.pm with the new request changes: `my $dir = "/home/dist"; run perl6 -I. -Ilib -e "require <Build.pm>; ::('Build').new.build('$dir'); exit(0);";` | 20:24 | |
|
20:35
cognominal joined
|
|||
| nine | Actually the gold standard would be to not need any hooks at all because we have declarative ways for everything a dist needs for building | 21:01 | |
| perlpilot starts to get a Dist::Zilla feeling | 21:04 | ||
| ugexe | gold standard for a package manager, not for core | ||
| autarch | I started playing with a Dist::Zilla type thing but got distracted by test infrastructure | 21:05 | |
| github.com/autarch/perl6-Dist-Wocky | |||
| flussence | I've pared my toolchain wishlist down to one item: something that allows me to write "./configure && make && make DESTDIR=$foo install" in any perl6 module directory with a reasonably high success rate. My reasoning is that if that's possible, everything else is in a sane state. | 22:14 | |
|
22:24
sufrostico joined
|
|||
| autarch | flussence: do you literally mean "make" or just something like that? | 22:30 | |
| cause I'd really hate to see EUMM6 | |||
| and I suspect in an ideal world there's nothing like configure either - for the vast majority of modules, you don't need to execute a script to configure it, you just need some metadata | 22:31 | ||
| I could see building in an escape hatch for "execute this to get this config value" for some use cases | |||