From owner-freebsd-questions@freebsd.org Wed Aug 19 06:15:31 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 860A93B2FC9 for ; Wed, 19 Aug 2020 06:15:31 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BWcw21tP3z4GDh for ; Wed, 19 Aug 2020 06:15:29 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([178.12.45.27]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPA (Nemesis) id 1MPXMa-1kLyTX0c30-00MZee; Wed, 19 Aug 2020 08:15:25 +0200 Date: Wed, 19 Aug 2020 08:15:24 +0200 From: Polytropon To: Cc: , Subject: Re: How to build a package from local source keeping all the original used (gnu autotools) build options !?? Message-Id: <20200819081524.f15f3ad7.freebsd@edvax.de> In-Reply-To: <000201d675eb$91f4eb40$b5dec1c0$@xs4all.nl> References: <000001d67566$e2acd5a0$a80680e0$@xs4all.nl> <000701d67598$0c8aa560$259ff020$@xs4all.nl> <20200819041750.5784a1f9.freebsd@edvax.de> <000201d675eb$91f4eb40$b5dec1c0$@xs4all.nl> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:6Z+d0gcSd4k8477YTIhdAMh61gPNHiBalaoRfDgbZ+XOJEd5w5m BTJPcDbRFzn4Dh8y15ndaAlNAGQ9p2bgiribjyDHsJVgR/T4eTYd3qtEa0PdREkEQI50HSU EWybycGBFIYI+e89rG8lI3KhSZA6M/XYpKDn1r1d9n9hPj/k5WA5BNesN4i+h6jIm5Lcgpe fFyDkHBphcl4vgcL6JNGw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:8DE/itWrvFs=:amhOKQi+KErDZvy5rpDPLE 0KQpffcqE3S6dMmcpboha+s5zcANYT1gxaZgzkZLmkWX36kP4XOk0cIFZOrfC1buNPMlIUKDG eypulVRSMbXGM/i/ptS/YvHELqg/2B94Ux8t/2aufEi/sB1TQ0VeB7tqJYH+B9YEy/ETRLC8E 0SIjJnGJestB7w2+YN/fv+IwWFMrh7evin0vsnz/Ne9HWcX+Z/GuvhLi4V2iyxmwm38oix5sr CGOQbbkHOMx3k5yVuv6SFzbdv0/dyFz2x1r+b1KTLlYpsWUOSPDg2LKBCiMvCAaK1U/+1QNFp 02k1QE01A98sEzLeRn2/VBT2kzAVrzWKopdcyQqqtlHM9a37accEV+izq1A2nnbQYBA4KA50K oNSfJXAMeG4Po/MnOs4cCYYq3QudSZwPrr/euEyNSr3myfm1nJOVSLfZ/0UefYj4vjpjOK0Yy r5oSFtu8rXEk2ocGCw2JzDu8BT/dnkeg10trMMytMjzfwG+k1rkCCrLpqma+wuP6wrO7oury7 LWydT/3+msOWvwQ4hZ0hjVMkX1gLnUacQ0BGljCtRumLau0FtD+4DYZX9H8AgJaN0kpzW0Aaq oa4uYzrOvOCentLUxFq+v7fwYpvuACmtUXALO3YqlxjsmQ1vvVk5DMSSDDyRV4hCWk6PBZrww cpqra65C1ijxKtKxLIcBkLEF1J9qHghBUX16H1KXwbZVVtezWvXeVgVHnyIAlyyuqGi7eXAEg psQ7938+s8eJ2H0eWxqiZs55nTw3ooOvR6Wy/VvI+/1Z1HiKABvqzYz++lt68d58K4xeY9USO 9ldEGlhodb2ut4z7UdGnl3Z+yOIatq5jzZZz/RZH7SzK73ZHTkbbSBm/53RDCR1dKcthTTj X-Rspamd-Queue-Id: 4BWcw21tP3z4GDh X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 212.227.17.24) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [3.72 / 15.00]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; FREEMAIL_TO(0.00)[xs4all.nl]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[178.12.45.27:received]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.32)[0.315]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[212.227.17.24:from]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.24:from]; FREEMAIL_CC(0.00)[xs4all.nl,freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 06:15:31 -0000 On Wed, 19 Aug 2020 07:42:46 +0200, l.m.v.breda@xs4all.nl wrote: > Thanx, > > Yep I am using outlook 😊 doing ..... clever things ...... Courtesy of software: "We know better than you." ;-) > Not only outlook by the way ..... no idea what this forum mailing > system is doing, but the layout of the mail here is ..... terrible > ..... not at all the intended layout !! Going with plain text / pure ASCII, no HTML, no "smart formatting", is the best thing to do. However, "clever" tools which know better than you will change your message and destroy the formatting you did, or destroy the formatting of the incoming messages so it's "more fun" for you to read. If you can, switch off all that "cleverness" for this mailing list - it just results in misleading and wrong content in the list and its archives. By the way, you can check the mailing list archives to see how the messages are supposed to look like (form-wise). ;-) > But back to the problem, what I IMHO has been doing, seems quite logical. > > Starting with the "maintainer part" ("maintainer process") > - sources are coming from GitHub, I did some local modifications > - so I am using the local git tree as the development tree > - generating a distribution file there That is already the problem where you see the interference with the ports system: Sources managed, build and installed with ports tools have to meet certain specifications. Sources obtained from Github, being processed outside of the scope of the ports toolchain, do not integrate well. See "man 7 ports" for details. > Than I distribute to port to generate the package to > "OS package maintainers" ("package build process") > - and yep it is on the same computer, but what is wrong with that .... > > Like you wrote, I probably need to build with ports itself. > Which breaks the whole idea of distribution files / responsibility > separation IMHO!! ☹ ☹ Port maintainers who develop software for FreeBSD tend so work with a local ports tree, and often use poudriere as a build environment. FreeBSD uses SVN (Subversion) as a revision control system for the ports tree itself. Port maintainers can use git / Github independently, but those are not part of the FreeBSD ports "ecosystem". I mention this as using portsnap will not always give you the most current version of the ports tree, that's why using svn checkout is preferred in such a case. > I am worried .... The package is designed to use "GNU-autotools > options .... not to use port options .... > does port allow to build the same way .... as does autotools > does ?? does > ./autogen.sh > ./configure – option-A=/abc – option-B=/def etc (*required* > work in ports !!??!!! This is something that the port's Makefile can communicate to the ./configure step. The port's options framework should be used to allow the user to define options as you mentioned, they usually aren't to be set manually: port options ---> ./configure options ---> build [ ] FOO --option-FOO=1 [ ] BAR --option-bar=enable [ ] BAZ --with-baz (Again, "cleverness" changed "--" to "– " which is wrong.) A first step is to determine if if you find some ./configure or autotools settings in that port which do not have a suitable option (selectable in "make config" or using a Makefile.local additional file). > May be there is no problem, have to find out. May be you are > willing to help here. There are more people on this list who are deeper involved in port management and development, they can probably offer a much more detailed and accurate answer. However, what you could try, is to use the ports collection as intended: Get the latest version of the tree, diff that against the tree obtained with git (just in case it's not current), and check or uncheck the options in "make config"; if you find options missing, e. g., there is some ./configure setting like --option-blah=xyz, but the port does not have a corresponding port option WITH_BLAH, you could add that experimentally, and if it works as intended, offer a patch to help the further development of the port in question. This eliminates the problem that there is an option the ports framework is not aware of, and therefore cannot handle it properly. The core idea is to move the sources for use into the correct place within the ports collection, both as "the files" and "the concepts" (options). > Assume I copy the whole source from my git directory to > "what ever other directory on my computer", which commands > should I use to get the intended result ........... The sources used to build within the ports tree belong into /usr/ports///. Without further knowledge about what you're trying to achieve, I cannot recommand exact commands to be entered. But the general path should be clear now. You can find more information here: 4.5. Using the Ports Collection https://www.freebsd.org/doc/handbook/ports-using.html 4.6. Building Packages with Poudriere https://www.freebsd.org/doc/handbook/ports-poudriere.html FreeBSD Porter's Handbook https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ Especially sctions 4, 5.13, 6.6 and therefore 17.4 seem to be valuable here, as well as example 5.10 (related to GitHub). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...