How to build a package from local source keeping all the original used (gnu autotools) build options !??
freebsd at edvax.de
Wed Aug 19 06:15:31 UTC 2020
On Wed, 19 Aug 2020 07:42:46 +0200, l.m.v.breda at xs4all.nl wrote:
> 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
> ./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
You can find more information here:
4.5. Using the Ports Collection
4.6. Building Packages with Poudriere
FreeBSD Porter's 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).
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions