[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Stow-devel] Stow 2.0.x release requirements

From: Adam Spiers
Subject: Re: [Stow-devel] Stow 2.0.x release requirements
Date: Wed, 23 Nov 2011 13:20:28 +0000

On Wed, Nov 23, 2011 at 12:02 AM, Kahlil Hodgson <address@hidden> wrote:
> Hi Adam,
> On 20/11/11 22:29, Adam Spiers wrote:
>> Good news!  I've finished split the core code off into two new
>> modules: and Stow/  I'm quite pleased that the process
>> of separating the frontend from the backend seems to have resulted in
>> some nice clean code - hope you agree when you see it.
>> provides a nice object-oriented interface, e.g.
>>     my $stow = new Stow(%$options);
>>     $stow->plan_unstow(@pkgs_to_unstow);
>>     $stow->plan_stow  (@pkgs_to_stow);
>>     my @conflicts = $stow->get_conflicts;
>>     $stow->process_tasks() unless @conflicts;
>> This enabled a *huge* reduction in the number of global variables.
>> All the options and state (@Tasks, @Conflicts etc.) are now stored
>> inside a Stow object instance.  This made for cleaner tests -
>> reset_state() is now obsolete, since to reset state you simply
>> instantiate a new Stow object.
> Very Nice :-)
>> After modifying the whole test suite to this new interface, I was able
>> to introduce 'use strict' and 'use warnings' to all the tests, and
>> 'make test' now passes 100% again :-)
> Excellent!
>> Latest code is available here:
> Hope to get a chance to check it out soon.  A little busy with work ATM.

I've made a lot more progress since the last mail.  Now I have a
comprehensive ignore files system (including new documentation and
tests) almost ready - just need to tweak the file syntax a bit.

>> and also adding Module::Build support so that we can easily make CPAN
>> releases.
> There be dragons.

The dragons are already slain - I've done this :)

> The older MakeMaker stuff may be easier.

I have experience with both systems but I deliberately chose
Module::Build because (a) it autogenerates a Build script rather than
a Makefile and so doesn't clash with autotools, and (b) it seems to be
a cleaner approach overall (I attended a talk by the author years ago)
which I find pretty easy to use.

>> I'm hoping that this will co-exist peacefully with the
>> autotools-based build system, although I'm currently puzzling over how
>> to cope with installation of the modules.  Module::Build expects them
>> to be under lib/, but if I put this in
>>   pmdir = $(libdir)/perl5
>>   nobase_pm_DATA = lib/ lib/Stow/
>> then autotools installs them to lib/perl5/lib/Stow* which is not
>> right :-/
> Getting the original autotools stuff to work really did my head in.  Had
> to read a lot of documentation just to do something very simple.
> I believe I may have forgotten almost everything I once new about the
> autotools framework now :-(

Don't worry - I already figured it all out.  I'll continue to upload
to my github until either Troy reappears or someone can give me
co-maintainer access.  I'm also pretty much ready to upload to CPAN
but am not sure whether that would be good etiquette before being
"officially" recognised as co-maintainer.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]