Date: Sat, 1 Jan 2000 19:46:11 -0600 From: Karl Denninger <karl@Denninger.Net> To: Steve Price <sprice@hiwaay.net> Cc: freebsd-ports@FreeBSD.ORG Subject: Re: ports/15822: Update port misc/HomeDaemon to V0.99 Message-ID: <20000101194611.A17603@Denninger.Net> In-Reply-To: <Pine.OSF.4.21.0001011713020.3979-100000@fly.HiWAAY.net>; from Steve Price on Sat, Jan 01, 2000 at 05:41:46PM -0600 References: <20000101165315.A17259@Denninger.Net> <Pine.OSF.4.21.0001011713020.3979-100000@fly.HiWAAY.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 01, 2000 at 05:41:46PM -0600, Steve Price wrote:
> On Sat, 1 Jan 2000, Karl Denninger wrote:
>
> # The only issue I'd have at first glance is that I have install targets in
> # the real package Makefile that already do the installation, so putting it
> # here is redundant (and breaks installing from a NON-PORT environment,
> # which I dislike as some people are on Linux!) I'd have to look at
>
> The number one reason that I did it this way is so that I didn't
> have to change four of your files. I did what I needed to do without
> disrupting your files. This is good because now you are free to
> change your files any way you want and chances are the effects to
> the port will be minimal.
Well, yes, maybe ;-)
But I DO NOT like targets in the port Makefile. They make the port version
non-common with the non-port version. That's why I avoided 'em in the first
place.
Now looking for things in the non-port's Makefile and doing things based on
them is ok, but not the other way around.
I'm NOT going to maintain two SEPARATE bases of code, one for FreeBSD-Ports
and one for everyone else. As such the "one" has to work both ways, or the
Ports lose - that much is simple (widest audience for ONE version is a
non-port one)
> # interactions between the defined prefixes and those scripts - my
> # intent is to have a package that works either stand-alone or as a
> # port.
> #
> # There's also a basic problem in that moving the package out of /usr/local
> # to an arbitrary place will break an *INTERNAL* execute call - the
> # HomeDaemon-events program calls -parse internally as a piped command
> # and it along with a few other things have #DEFINEd constants in defs.h
> # for where their config files and working directories are.
>
> This is quite easy to fix from the port's Makefile.
>
> post-patch:
> .for f in defs.h Defaults/HomeDaemon.rc
> ${PERL} -pi -e 's,/usr/local,${PREFIX},g' ${WRKSRC}/${f}
> .endfor
That's even more ill , as its a one-way road. No thanks.
> # As such you have to be *very* careful about arbitrary movements of
> # files. That's the primary reason I left the install locations hard-coded
> # in the Makefile-called install targets. I suppose I could do definitions
> # of undefined targets in the package Makefile itself and pass that through
> # CFLAGS; that would be an acceptable means of getting around this.
> #
> # The "-s" is "strip" - it strips the symbols from the output of "cc".
> # It typically does nothing (but also no harm) for a compile, but is
> # effective on the link phase.
>
> Doh! I knew that. Sorry for the dumb question.
:-)
> # The bottom line is that it saves a "strip" on the installation phase to get
> # minimum-size installed binaries.
> #
> # Let me do a bit more hacking on this and get back to you - do you want a new
> # "shar" when I'm done or do you want diffs?
> #
> # The new shar is likely to be smaller.
>
> You can send me either one. I already have a couple of other changes
> to the one I sent you. :)
>
> -steve
Ok.
--
--
Karl Denninger (karl@denninger.net) Web: http://childrens-justice.org
Isn't it time we started putting KIDS first? See the above URL for
a plan to do exactly that!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000101194611.A17603>