Bug#862604: dh-make-elpa: extending create_docs{}

[Lev Lamberov]

Ср 21 мар 2018 @ 14:21 Sean Whitton :

> On Tue, Mar 20 2018, Lev Lamberov wrote:
>
>> Do you think the bug should be closed? As I understand, this change is
>> what you'd like to have compared to a more complex change with
>> multiple docs files for multiple "binaries"?
>
> Seems fine to close the bug because it is not clear what automation
> would be desirable.

Added an indication to d/changelog that it closes the bug.

Cheers!
Lev

Bug#862604: dh-make-elpa: extending create_docs{}

[Sean Whitton]

Hello,

On Tue, Mar 20 2018, Lev Lamberov wrote:

> Done.

Thanks.

> Do you think the bug should be closed? As I understand, this change is
> what you'd like to have compared to a more complex change with
> multiple docs files for multiple "binaries"?

Seems fine to close the bug because it is not clear what automation
would be desirable.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#862604: dh-make-elpa: extending create_docs{}

[Lev Lamberov]

Пн 19 мар 2018 @ 20:43 Sean Whitton :
> On Sat, Mar 17 2018, Lev Lamberov wrote:
>
>> Please, find the patch attached.
>
> Thank you for working on this!
>
> If you've tested the patch and it works, please go ahead and apply to
> the repository and add a changelog entry closing this bug.

Done.

Do you think the bug should be closed? As I understand, this change is
what you'd like to have compared to a more complex change with multiple
docs files for multiple "binaries"?

Cheers!
Lev

Bug#862604: dh-make-elpa: extending create_docs{}

[Sean Whitton]

Hello Lev,

On Sat, Mar 17 2018, Lev Lamberov wrote:

> Please, find the patch attached.

Thank you for working on this!

If you've tested the patch and it works, please go ahead and apply to
the repository and add a changelog entry closing this bug.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#862604: dh-make-elpa: extending create_docs{}

[Lev Lamberov]

Hi,

I've changed create_docs function a bit in such a way that now it
supports md, markdown, mdwn, and org documentation. The d/docs file is
filled with the exact filenames one per line if the file extension is
one of {md,markdown,mdwn,org} (case insensitive).

>> Also, if there will be package-name-based heuristics then I'm guessing
>> any potential-doc-type.files that match a hungry glob for "first"
>> could go into elpa-first.doc, anything that matches "second" and not
>> "first" would go into elpa-second.doc, and anything that doesn't match
>> either can go into something like needs-review.doc.  That last one
>> ought to produce a lintian error and force manual review.

> I think this would be overly complex and rarely correct.  I'd prefer
> just to dump everything in debian/docs, and let the user split it.

I agree, so in my solution everything is dumped to the single d/docs
file for latter splitting just in case it's needed.

Please, find the patch attached.

Regards,
Lev Lamberov

>From 7bef3069934c555ca1ccf7ea42b884f00e597bed Mon Sep 17 00:00:00 2001
From: Lev Lamberov 
Date: Sat, 17 Mar 2018 23:23:31 +0500
Subject: [PATCH] Add support for md, markdown, mdwn, and org documentation
 files

---
 lib/DhMakeELPA/Command/Packaging.pm | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/lib/DhMakeELPA/Command/Packaging.pm b/lib/DhMakeELPA/Command/Packaging.pm
index 40a440a..47d5304 100644
--- a/lib/DhMakeELPA/Command/Packaging.pm
+++ b/lib/DhMakeELPA/Command/Packaging.pm
@@ -289,14 +289,19 @@ sub create_gbp_conf {
 }
 
 # TODO more complex case with more than one binary package
-# TODO support .markdown, .mdwn etc.
 sub create_docs {
 my $self = shift;
-my @docs = glob($self->main_dir . "/*.md");
+
+my $doc_regexp = qr/\.md$|\.markdown$|\.mdwn$|\.org$/i;
+opendir my $dh, $self->main_dir or die "$0: Unable to open directory: $!";
+my @docs = grep { /$doc_regexp/ && -f "$self->{main_dir}/$_" } readdir($dh);
+closedir $dh;
 
 if ( keys %{$self->bins} le 1 && scalar @docs gt 0 ) {
 my $fh = $self->_file_w( $self->debian_file('docs') );
-$fh->print( "*.md\n" );
+for (@docs) {
+$fh->print( "$_\n" );
+}
 $fh->close;
 } else {
 print "I: couldn't generate d/docs: not fully implemented\n";
-- 
2.16.2

Bug#862604: dh-make-elpa: extending create_docs{}

[Sean Whitton]

Hello Nicholas,

On Sun, May 14, 2017 at 10:45:54PM -0400, Nicholas D Steeves wrote:
> I thought I'd take a quick look at dh-make-elpa's create_docs, because
> I've been using dh-make-elpa a lot recently.  What do you think of
> iteratively printing (filename\n) from a list generated from *.md and
> *.org instead of checking for an *.md and writing "*.md\n"?  Then the
> file (containing an \n separated list) could be copied/moved to
> package1.docs and package2.docs and the items not relevant to
> $packageX could simply be cut from its packageX.docs.  That's more or
> less way I do it from the shell.

Sounds good to me.

> Also, if there will be package-name-based heuristics then I'm guessing
> any potential-doc-type.files that match a hungry glob for "first"
> could go into elpa-first.doc, anything that matches "second" and not
> "first" would go into elpa-second.doc, and anything that doesn't match
> either can go into something like needs-review.doc.  That last one
> ought to produce a lintian error and force manual review.

I think this would be overly complex and rarely correct.  I'd prefer
just to dump everything in debian/docs, and let the user split it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#862604: dh-make-elpa: extending create_docs{}

[Nicholas D Steeves]

Package: dh-make-elpa
Version: 0.7.1
Severity: wishlist

Hi Sean,

I thought I'd take a quick look at dh-make-elpa's create_docs, because
I've been using dh-make-elpa a lot recently.  What do you think of
iteratively printing (filename\n) from a list generated from *.md and
*.org instead of checking for an *.md and writing "*.md\n"?  Then the
file (containing an \n separated list) could be copied/moved to
package1.docs and package2.docs and the items not relevant to
$packageX could simply be cut from its packageX.docs.  That's more or
less way I do it from the shell.

Also, if there will be package-name-based heuristics then I'm guessing
any potential-doc-type.files that match a hungry glob for "first"
could go into elpa-first.doc, anything that matches "second" and not
"first" would go into elpa-second.doc, and anything that doesn't match
either can go into something like needs-review.doc.  That last one
ought to produce a lintian error and force manual review.

Cheers,
Nicholas


signature.asc
Description: Digital signature