Date: Wed, 19 Aug 2020 08:15:24 +0200 From: Polytropon <freebsd@edvax.de> To: <l.m.v.breda@xs4all.nl> Cc: <louis.forums@xs4all.nl>, <freebsd-questions@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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/<category>/<name>/<work>. 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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200819081524.f15f3ad7.freebsd>