Date: Tue, 1 Apr 2014 10:55:14 -0400 (EDT) From: "Phil Law" <3@boltoncctv.com> To: freebsd-arch@freebsd.org Subject: CCTV Message-ID: <20140401145514.453968BE18@pmta4-1-06>
next in thread | raw e-mail | index | archive | help
Hi, We can install a CCTV at your house or business for the following price. 1 Camera system =C2=A3370 2 Camera system =C2=A3420 3 Camera system =C2=A3595 4 Camera system =C2=A3645 Would you like me to arrange this for you? You get the following with all our systems. - See the cameras on your mobile. - High quality cameras with wide lens. - High capacity storage. - Infrared night vision. - Includes all parts and labour. - Includes cameras and recorder. - 1 years hardware warranty. We can beat any like for like price. Our engineers can install a system anywhere in the UK* Regards, Bolton CCTV Telephone: 01204 216810 Website: http://link.mailanimal01.com/c/443/0208232bdba84e2c76c0a1d09ccf= 1643b2aa54783420edd279d4a3b3d0148ef5 Address: 3 Churchbank, Bolton, BL1 1HX * Additional costs for any location which is more than 50 miles from our= offices. Unsubscribe from this mailing list: http://link.mailanimal01.com/u/443/0= 208232bdba84e2c76c0a1d09ccf1643a3a380962ac20e9f From owner-freebsd-arch@FreeBSD.ORG Tue Apr 1 16:59:48 2014 Return-Path: <owner-freebsd-arch@FreeBSD.ORG> Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96B6DAAE; Tue, 1 Apr 2014 16:59:48 +0000 (UTC) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BA41EC8; Tue, 1 Apr 2014 16:59:47 +0000 (UTC) Received: from mail174-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.22; Tue, 1 Apr 2014 16:29:29 +0000 Received: from mail174-ch1 (localhost [127.0.0.1]) by mail174-ch1-R.bigfish.com (Postfix) with ESMTP id 01E511004D7; Tue, 1 Apr 2014 16:29:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1082kzz1de097hz31h2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h224fh1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h226dh22d0h24afh2327h2336h2381h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26d3h1155h) Received-SPF: softfail (mail174-ch1: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=sjg@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail174-ch1 (localhost.localdomain [127.0.0.1]) by mail174-ch1 (MessageSwitch) id 1396369766733884_5064; Tue, 1 Apr 2014 16:29:26 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail174-ch1.bigfish.com (Postfix) with ESMTP id AED00C00B2; Tue, 1 Apr 2014 16:29:26 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 1 Apr 2014 16:29:22 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 1 Apr 2014 09:29:21 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s31GTCV98295; Tue, 1 Apr 2014 09:29:16 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 7A9D058097; Tue, 1 Apr 2014 09:29:12 -0700 (PDT) To: Warner Losh <imp@bsdimp.com> Subject: Re: make WITH[OUT]_* more useful? In-Reply-To: <766EFF76-7B41-423F-B447-DBA25BD14470@bsdimp.com> References: <20140401051327.F20F958097@chaos.jnpr.net> <20140401064316.GQ99393@ivaldir.etoilebsd.net> <766EFF76-7B41-423F-B447-DBA25BD14470@bsdimp.com> Comments: In-reply-to: Warner Losh <imp@bsdimp.com> message dated "Tue, 01 Apr 2014 08:22:18 -0600." From: "Simon J. Gerraty" <sjg@juniper.net> X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Tue, 1 Apr 2014 09:29:12 -0700 Message-ID: <20140401162912.7A9D058097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Baptiste Daroussin <bapt@freebsd.org>, freebsd-arch@freebsd.org, sjg@juniper.net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>; List-Post: <mailto:freebsd-arch@freebsd.org> List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 01 Apr 2014 16:59:48 -0000 On Tue, 1 Apr 2014 08:22:18 -0600, Warner Losh writes: >>> re-implement the WITH_* vs WITHOUT_* logic repeatedly. > >Where, exactly, do we do this? In my recent gripping I=92ve found almost I hit this just about every possible way while trying to support WITH[OUT]_BMAKE in such a way that people could build head on 9 etc. Incluing in-tree bsd.own.mk so MK_BMAKE would get set - broke building on 9 IIRC. Being able to simply do MK_BMAKE?= {yes,no} would have been best solution. Also I normally want to built WITH_CTF, but of course you cannot simply put that in make.conf you have to .if !defined(WITHOUT_CTF) && !defined(NO_CTF) WITH_CTF=yes .endif else you get errors during buildworld. >>> It is also generally bad to include bsd.own.mk from sys.mk, which means >>> any knobs you need early must re-implement the WITH_* vs WITHOUT_* logic >>> repeatedly. > >Again, I find no evidence of this in the tree, can you cite specific exampl= It isn't done anymore (was certainly done back in 2.x, don't recall when it was removed), which is good, but means that sys.mk cannot use any MK_* that the user can influence via WITH[OUT]_*. That's not so much a problem for existing options, but makes it impractical to leverage the mechanism for things you might want to set during sys.mk - like whether to use meta mode or auto objdir creation. >I mostly hate this. Specifically, I don=92t like the DOMINANT bits. They ar= >e unnecessary. I mostly agree - I find it quite reasonable to simply allow WITHOUT to win. DOMINANT_* is just an "out" in case there's some future case I haven't thought of. The default behavior remains that WITHOUT wins. >WITH/WITHOUT is a user-only knob. Agreed, but the implementation renders it user unfriendly. If everywhere I want to set a default (eg make.conf) I have to do a dance like .if !defined(WITHOUT_CTF) && !defined(NO_CTF) WITH_CTF=yes .endif it isn't exactly helping me as much as it could. If the build stops using WITH/WITHOUT internally that probably helps. >The build system should never use it, but always >set MK_* directly. Agreed - that would be most useful and is one of the main changes in my version. >I recently fixed it so the build system can start doing = >that. This solves >the WITH and WITHOUT problem internally. That's good - being able to set MK_* directly without causing error does address the issue for the build itself. Alone though it doesn't necessarily make life any better for users who (per my example above) want to set defaults like WITH_CTF= in make.conf but occasionally override them. Unless they too are supposed to set MK_* directly but then what is the point of WITH[OUT]_* ? >I'm still not sure I see the big win. I have a number of knobs to be set during sys.mk AUTO_OBJ automatically create objdirs META_MODE use meta mode setting MK_* is fine, but it is nice if you allow the user to interact using WITH[OUT]_*, and for that it is best if sys.mk can safely include something like options.mk Of course the user can learn to MK_AUTO_OBJ=no but that simply devalues WITH[OUT]_* It is a neat mechanism, that with some minor tweaks could be much more useful. Baptiste writes: >> I would be interested in having your opinion on what we did for ports. It is a bit more elaborate (422 lines vs 59 in options.mk) that's probably a necessity for ports, but not so sure about inclusion by sys.mk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140401145514.453968BE18>