New: colortree

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

New: colortree

David Dahlberg-2
A port for Steve Baker's "tree" program.

As we have already a simpler, BSD-licenced alternative in ports, I used
the gnugetopt/coreutils/colorls approach and renamed to "colortree",
which is the author's preference.

Cheers,
        David

colortree.tgz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New: colortree

Vadim Zhukov
2015-07-19 18:09 GMT+03:00 David Dahlberg <[hidden email]>:
> A port for Steve Baker's "tree" program.
>
> As we have already a simpler, BSD-licenced alternative in ports, I used
> the gnugetopt/coreutils/colorls approach and renamed to "colortree",
> which is the author's preference.

1. Don't hardcode -O2, let the CFLAGS/COPTS/DEBUG coming from outside
port do their job instead... I propose getting out of GMake dependency
and just build the port yourself:

do-build:
        cd ${WRKBUILD}; ${CC} ${CFLAGS} -o tree ${WRKSRC}/*.c

2. After modifying the manual pages, some lines started to exceed 80
chars there.

3. "The tree command for linux" in COMMENT doesn't say anything useful.

--
  WBR,
  Vadim Zhukov

Reply | Threaded
Open this post in threaded view
|

Re: New: colortree

David Dahlberg-2
Am Sunday, den 19.07.2015, 19:43 +0300 schrieb Vadim Zhukov:
> 2015-07-19 18:09 GMT+03:00 David Dahlberg <[hidden email]
> >:
> > A port for Steve Baker's "tree" program.
> >
> 1. Don't hardcode -O2, let the CFLAGS/COPTS/DEBUG coming from outside
> port do their job instead... I propose getting out of GMake
> dependency
> and just build the port yourself:

After that change the dist Makefile is not used any more for the
ALL_TARGET, so patch-Makefile becomes unnecessary.

> 2. After modifying the manual pages, some lines started to exceed 80
> chars there.
>
> 3. "The tree command for linux" in COMMENT doesn't say anything
> useful.

Better this way?

colortree.tgz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New: colortree

Dmitrij D. Czarkoff-2
| CFLAGS = -Wall -fomit-frame-pointer

Just leave CFLAGS to user settings.  This port builds and works without
any CFLAGS definitions.

--
Dmitrij D. Czarkoff

Reply | Threaded
Open this post in threaded view
|

Re: New: colortree

Vadim Zhukov
In reply to this post by David Dahlberg-2
2015-07-19 21:10 GMT+03:00 David Dahlberg <[hidden email]>:

> Am Sunday, den 19.07.2015, 19:43 +0300 schrieb Vadim Zhukov:
>> 2015-07-19 18:09 GMT+03:00 David Dahlberg <[hidden email]
>> >:
>> > A port for Steve Baker's "tree" program.
>> >
>> 1. Don't hardcode -O2, let the CFLAGS/COPTS/DEBUG coming from outside
>> port do their job instead... I propose getting out of GMake
>> dependency
>> and just build the port yourself:
>
> After that change the dist Makefile is not used any more for the
> ALL_TARGET, so patch-Makefile becomes unnecessary.

Yes. But, please, remove CFLAGS line entirely then, too.

>> 2. After modifying the manual pages, some lines started to exceed 80
>> chars there.
>>
>> 3. "The tree command for linux" in COMMENT doesn't say anything
>> useful.
>
> Better this way?

Yes. The last small nit: the manual page isn't built but comes
directly from source directory, so the ${INSTALL_MAN} line should use
${WRKSRC} instead of ${WRKBUILD} there. You can feel the difference if
you'll add SEPARATE_BUILD=Yes to the port Makefile (you can do this to
fill the vacuum after CFLAGS line removal :) ).

After that the port is okay zhuk@ for whoever will want to import it.

--
  WBR,
  Vadim Zhukov

Reply | Threaded
Open this post in threaded view
|

Re: New: colortree

David Dahlberg-2
Am Sunday, den 19.07.2015, 22:01 +0300 schrieb Vadim Zhukov:
> Yes. But, please, remove CFLAGS line entirely then, too
[..]
> Yes. The last small nit: the manual page isn't built but comes
> directly from source directory, so the ${INSTALL_MAN} line should use
> ${WRKSRC} instead of ${WRKBUILD} there. You can feel the difference
> if
> you'll add SEPARATE_BUILD=Yes to the port Makefile (you can do this
> to
> fill the vacuum after CFLAGS line removal :) ).

Yes, now I see separate directories.
Here is the new tarball ...

colortree.tgz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New: colortree

Stuart Henderson-6
On 2015/07/20 18:52, David Dahlberg wrote:

> Am Sunday, den 19.07.2015, 22:01 +0300 schrieb Vadim Zhukov:
> > Yes. But, please, remove CFLAGS line entirely then, too
> [..]
> > Yes. The last small nit: the manual page isn't built but comes
> > directly from source directory, so the ${INSTALL_MAN} line should use
> > ${WRKSRC} instead of ${WRKBUILD} there. You can feel the difference
> > if
> > you'll add SEPARATE_BUILD=Yes to the port Makefile (you can do this
> > to
> > fill the vacuum after CFLAGS line removal :) ).
>
> Yes, now I see separate directories.
> Here is the new tarball ...

WANTLIB is missing.

Reply | Threaded
Open this post in threaded view
|

Re: New: colortree

David Dahlberg-2
Am Monday, den 20.07.2015, 18:03 +0100 schrieb Stuart Henderson:
> WANTLIB is missing.

Added it.

But what I still noticed is that the compiler warns about
strcpy/sprintf. Even though there are only two invocations of strcpy(3)
which do look good to me, there is actually far to many sprintf(3) with
lengthy strlen(3) calculations to take care of them all in a port.

Should I do something about that (except nagging at upstream)?

colortree.tgz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New: colortree

Vadim Zhukov
20 июля 2015 г. 21:15 пользователь "David Dahlberg"
<[hidden email]> написал:

>
> Am Monday, den 20.07.2015, 18:03 +0100 schrieb Stuart Henderson:
> > WANTLIB is missing.
>
> Added it.
>
> But what I still noticed is that the compiler warns about
> strcpy/sprintf. Even though there are only two invocations of strcpy(3)
> which do look good to me, there is actually far to many sprintf(3) with
> lengthy strlen(3) calculations to take care of them all in a port.
>
> Should I do something about that (except nagging at upstream)?

Just say upstream that OpenBSD devs will cut a finger from you each week
sprintf calls are kept in source. :) Don't mind, but some nagging in this
direction is always good.

--
Vadim Zhukov