On 9/28/18 5:21 PM, Bruce Dubbs via blfs-dev wrote: > On 09/28/2018 02:11 AM, Pierre Labastie via blfs-dev wrote: >> On 9/28/18 7:51 AM, Ken Moffat via blfs-dev wrote: >>> On Fri, Sep 28, 2018 at 12:17:07AM -0500, Bruce Dubbs via blfs-dev wrote: >>>> On 09/27/2018 11:54 PM, Ken Moffat via blfs-dev wrote: >>>>> I've updated the online rendered versions of the branch, again at >>>>> http://www.linuxfromscratch.org/~ken/perl-changes/ >>>>> >>>>> The versions shown on the front pages remain at 18th September, but >>>>> the individual pages are correctly labelled as 27th September. That >>>>> probably means I missed the date change in general.ent in the last >>>>> merege (I mistakenly thought I could just take trunk's version, >>>>> forgetting I had added cpan entities there - until the render blew >>>>> up). >>>>> >>>>> Only another 100 or so modules to get through ;) >>>>> >>>>> Comments still welcome. >>>> >>>> I like what you've done. >>> >>> Thanks. >>> >>>> It makes things a lot easier. One thing though. >>>> In most packages you have: >>>> >>>> This module uses the standard build and installation instructions: >>>> >>>> perl Makefile.PL && >>>> make && >>>> make test >>>> >>>> Now, as the root user: >>>> >>>> make install >>>> >>>> And that is repeated over and over. Why not make "standard build and >>>> installation instructions" a symlink to a common section similar to the old >>>> page? Just list the specific instructions where there is something >>>> different (like Encode::HanExtra and Text::BibTeX). > >>> It was Pierre's suggestion, to simplify things for jhalfs (and in >>> particular, for modules where there were differences such as applying >>> a patch e.g. as Data::Uniquid, as was - patch now removed as >>> unnecessary). > >> I know it is boring to see all those similar instructions. As it is now, >> there >> is no need to change anything in jhalfs to be able to build all the perl >> modules on the new page. If you make a symlink, jhalfs will have to follow >> this link. That would not be hard if there were only one set of instructions. >> But if there are special cases (such as using Module::Build or something more >> specific), there should be a flag (remap attribute?) in the xml to direct >> jhalfs to use the correct instructions. With the former perl module page >> layout (such as what is in trunk), jhalfs was relying on the xref in the text >> to get the instructions right, but it was almost always failing when >> something >> specific was needed... As you know, it is hard to analyze text in XSL >> translation. >> >> So for now, I suggest waiting for completion of the new page. Then the >> instruction entities could be replaced with just a sentence, and a remap in >> the xref. > > How about this: > > <xref remap="perl-instr" linkend="perl-std"/> > > And have blfs key off of "perl-instr" to use > > perl Makefile.PL && > make && > make test && > sudo make install > > Or similar. >
I was thinking of something similar. I've not checked that xref accepts the remap attribute, though. Note that since we have an xi:include for standard and "Module::Build" instructions, it is just a matter of modifying the "xi:include"d file, and reinstate the paragraph on standard and "Module::build" build instructions. But then the xsl prgoram for jhalfs will need to be modified too. That's why I think it is better to wait for the end of the perl modules move, test that everything is OK for jhalfs this way, then change the xi:include file and the jhalfs xsl file. If something gets wrong when you take several actions, you don't know which action is to blame. So let's do things sequentially. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
