[new] dhex port (0.62/all fixed)

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

[new] dhex port (0.62/all fixed)

ramrunner
ok list.
here is a new port of the newest version of dhex that
has string searching capabilities and some bugfixes.
the maintainer was kind enough to provide that after marcos request.
also the new port has WANTLIB, and -03 flags , but somebody
could just mention it before...

cheers
DsP

dhex-port.tar.gz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [new] dhex port (0.62/all fixed)

ramrunner
just to be correct i meant the developer was kind enough to provide
that :) ... sorry for the extra mail.

On Thu, Jan 13, 2011 at 5:35 PM, ramrunner <[hidden email]> wrote:

> ok list.
> here is a new port of the newest version of dhex that
> has string searching capabilities and some bugfixes.
> the maintainer was kind enough to provide that after marcos request.
> also the new port has WANTLIB, and -03 flags , but somebody
> could just mention it before...
>
> cheers
> DsP
>

Reply | Threaded
Open this post in threaded view
|

Re: [new] dhex port (0.62/all fixed)

Matthias Kilian
In reply to this post by ramrunner
On Thu, Jan 13, 2011 at 05:35:28PM +0200, ramrunner wrote:
> here is a new port of the newest version of dhex that
> has string searching capabilities and some bugfixes.
> the maintainer was kind enough to provide that after marcos request.
> also the new port has WANTLIB, and -03 flags, but somebody
> could just mention it before...

Why -O3?

Why ${INSTALL_SCRIPT} in do-install? It isn't a script.

Not going to look at the port even further.

Reply | Threaded
Open this post in threaded view
|

Re: [new] dhex port (0.62/all fixed)

Stuart Henderson
In reply to this post by ramrunner
On 2011/01/13 17:35, ramrunner wrote:
> ok list.
> here is a new port of the newest version of dhex that
> has string searching capabilities and some bugfixes.
> the maintainer was kind enough to provide that after marcos request.
> also the new port has WANTLIB, and -03 flags , but somebody
> could just mention it before...

- We don't set optimization CFLAGS in a port Makefile, unless there
is a specific reason the software is broken with other settings
(examples of when it's valid: some software requires -O or -O0
otherwise build fails, other software usually involving asm code
on i386 may require certain settings to ensure enough registers
are available).

- Use ${INSTALL_PROGRAM} for a binary, it handles stripping correctly.

- Specify the license version before PERMIT_*.

- Should honour CC and CFLAGS passed in from the system.

updated tgz attached.




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

Re: [new] dhex port (0.62/all fixed)

Marco Peereboom
groovy!

could you get that in?

On Fri, Jan 14, 2011 at 08:59:02PM +0000, Stuart Henderson wrote:

> On 2011/01/13 17:35, ramrunner wrote:
> > ok list.
> > here is a new port of the newest version of dhex that
> > has string searching capabilities and some bugfixes.
> > the maintainer was kind enough to provide that after marcos request.
> > also the new port has WANTLIB, and -03 flags , but somebody
> > could just mention it before...
>
> - We don't set optimization CFLAGS in a port Makefile, unless there
> is a specific reason the software is broken with other settings
> (examples of when it's valid: some software requires -O or -O0
> otherwise build fails, other software usually involving asm code
> on i386 may require certain settings to ensure enough registers
> are available).
>
> - Use ${INSTALL_PROGRAM} for a binary, it handles stripping correctly.
>
> - Specify the license version before PERMIT_*.
>
> - Should honour CC and CFLAGS passed in from the system.
>
> updated tgz attached.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [new] dhex port (0.62/all fixed)

Stuart Henderson
In reply to this post by Stuart Henderson
On 2011/01/14 20:59, Stuart Henderson wrote:

> On 2011/01/13 17:35, ramrunner wrote:
> > ok list.
> > here is a new port of the newest version of dhex that
> > has string searching capabilities and some bugfixes.
> > the maintainer was kind enough to provide that after marcos request.
> > also the new port has WANTLIB, and -03 flags , but somebody
> > could just mention it before...
>
> - We don't set optimization CFLAGS in a port Makefile, unless there
> is a specific reason the software is broken with other settings
> (examples of when it's valid: some software requires -O or -O0
> otherwise build fails, other software usually involving asm code
> on i386 may require certain settings to ensure enough registers
> are available).
>
> - Use ${INSTALL_PROGRAM} for a binary, it handles stripping correctly.
>
> - Specify the license version before PERMIT_*.
>
> - Should honour CC and CFLAGS passed in from the system.
>
> updated tgz attached.

bleh, superfluous WRKDIST that I didn't notice earlier; I won't
bother with a new tarball but I've zapped it from my tree.
would any ports hacker like to give an ok?


Reply | Threaded
Open this post in threaded view
|

Re: [new] dhex port (0.62/all fixed)

David Coppa
On Fri, Jan 14, 2011 at 10:19 PM, Stuart Henderson <[hidden email]> wrote:

> On 2011/01/14 20:59, Stuart Henderson wrote:
>> On 2011/01/13 17:35, ramrunner wrote:
>> > ok list.
>> > here is a new port of the newest version of dhex that
>> > has string searching capabilities and some bugfixes.
>> > the maintainer was kind enough to provide that after marcos request.
>> > also the new port has WANTLIB, and -03 flags , but somebody
>> > could just mention it before...
>>
>> - We don't set optimization CFLAGS in a port Makefile, unless there
>> is a specific reason the software is broken with other settings
>> (examples of when it's valid: some software requires -O or -O0
>> otherwise build fails, other software usually involving asm code
>> on i386 may require certain settings to ensure enough registers
>> are available).
>>
>> - Use ${INSTALL_PROGRAM} for a binary, it handles stripping correctly.
>>
>> - Specify the license version before PERMIT_*.
>>
>> - Should honour CC and CFLAGS passed in from the system.
>>
>> updated tgz attached.
>
> bleh, superfluous WRKDIST that I didn't notice earlier; I won't
> bother with a new tarball but I've zapped it from my tree.

The "-Wall" in CFLAGS is superfluous too:

MAKE_FLAGS = CC="${CC}" CFLAGS="${CFLAGS} -std=c99"

should be sufficient. But, apart from this, it's OK for me.

Ciao,
David

Reply | Threaded
Open this post in threaded view
|

Re: [new] dhex port (0.62/all fixed)

Stuart Henderson
On 2011/01/14 23:00, David Coppa wrote:

> On Fri, Jan 14, 2011 at 10:19 PM, Stuart Henderson <[hidden email]> wrote:
> > On 2011/01/14 20:59, Stuart Henderson wrote:
> >> On 2011/01/13 17:35, ramrunner wrote:
> >> > ok list.
> >> > here is a new port of the newest version of dhex that
> >> > has string searching capabilities and some bugfixes.
> >> > the maintainer was kind enough to provide that after marcos request.
> >> > also the new port has WANTLIB, and -03 flags , but somebody
> >> > could just mention it before...
> >>
> >> - We don't set optimization CFLAGS in a port Makefile, unless there
> >> is a specific reason the software is broken with other settings
> >> (examples of when it's valid: some software requires -O or -O0
> >> otherwise build fails, other software usually involving asm code
> >> on i386 may require certain settings to ensure enough registers
> >> are available).
> >>
> >> - Use ${INSTALL_PROGRAM} for a binary, it handles stripping correctly.
> >>
> >> - Specify the license version before PERMIT_*.
> >>
> >> - Should honour CC and CFLAGS passed in from the system.
> >>
> >> updated tgz attached.
> >
> > bleh, superfluous WRKDIST that I didn't notice earlier; I won't
> > bother with a new tarball but I've zapped it from my tree.
>
> The "-Wall" in CFLAGS is superfluous too:
>
> MAKE_FLAGS = CC="${CC}" CFLAGS="${CFLAGS} -std=c99"
>
> should be sufficient. But, apart from this, it's OK for me.

the original Makefile uses it and I didn't see a reason not to,
but yes that could go, we might as well zap -std=c99 too in that
case (I guess upstream just use it to try and avoid gnu-isms in
their code).