Re: What is the actual syntax used to FLAVOR ports?
On Mon, Feb 10, 2020 at 09:02:34PM -0500, Ernie Luzar wrote: > Kevin Oberman wrote: > > On Sat, Feb 8, 2020 at 1:27 PM Chris wrote: > > > > > OK I know FLAVOR is an evolving concept. But I can not find > > > the FLAVOR documentation. Only references in the porters > > > handbook. What I think needs to be available is an entire > > > list of flavor tags for all (port) categories. > > > For example; > > > make FLAVOR=python27 returns the error use py27. > > > OK now I know how to flavor, and build python flavors. > > > But what of Perl? > > > make FLAVOR=perl2.8. Nope. How about make FLAVOR=p5-28, > > > and so it goes... > > > Does there exist a definitive list of flavors? It'd > > > also be valuable for defining defaults in make.conf(5) > > > > > > Thanks! > > > > > > --Chris > > > > > > The problem is not having a clear understanding of what a FLAVOR is and > > when it is used. > > > > FLAVORS are generally a way to deal with the problem of incompatible > > versions and Python is the poster child. Python2 and Python3 are two > > version of a VERY popular language that have significant syntax > > incompatibilities. While a program written for gcc-4.2 should work fine > > when compiled with gcc-7, it is VERY unlikely that a program written for > > Python2 will work with Python3. While the changes needed are often fairly > > straight forward, they have to be made. The result is a requirement of > > having both interpreters installed and two packages of of most Python > > libraries built from a single source. > > > > Adding FLAVORS for a port is an expensive operation and is never lightly > > approved by the ports management team as it adds a great deal of complexity > > and both human and machine overhead. Requests to FLAVOR a port are > > carefully reviewed and will only be approved with adequate justification. > > > > In the case of Perl, no attempt to flavor it has been needed. Most Perl > > packages (p5-*) will work with any of the three available ports. In most > > cases they may be installed and continue to work across versions with no > > changes. Python (py-) ports MUST be reinstalled to move from Python2 to > > Python3. Some have not had required changes to work with Python3 made and, > > initially, almost none did. Some have now been written with no support for > > Python2. All of this has to be properly handled by the package building > > system and it is not at all trivial. > > > > As of today, I believe the only FLAVORed ports are those using emacs, > > lazarus, php, and, of course, python. By "using", I mean that the port > > Makefile includes "USE_PYTHON" or similar USE_ definitions of the other > > languages. (Yes, emacs is not a language, but elisp, the core of emacs, is > > and lazarus is an IDE for Pascal.) > > > > I'm sorry of this is not entirely clear, but I hope it helps and I hope it > > is all correct. I may have worded some of it poorly. > > -- > > Kevin Oberman, Part time kid herder and retired Network Engineer > > E-mail: rkober...@gmail.com > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > wow the above reply is not how I remember how things were envisioned when > this flavor function was first talked about. Having to get permission first > and being limited to languages was never talked about and not at all a > requirement. Having to get permissions was never envisioned, and we will stop having it as a requirement when people stop trying to forcefully do very silly things, it will probably be relaxed when we have subpackages. It is not at all limited to languages, I have no idea where that came from. You only have to grep for '^FLAVORS=' to see that. > It was envisioned as a way to per can a set of different > defaults so a package with pre canned defaults would be auto built in the > ports system that is different from the basic defaults. ON the subject of > documentation about how to set up flavors for a port is totally lacking at > this point. You know the old saying, developers are good programmers but are > terrible at documenting their work if they do it at all. So with that in > mind do your own thing following what you see for flavored languages as a > loosely followed guide. Flavors have been documented from day one. https://www.freebsd.org/doc/en/books/porters-handbook/flavors.html (I kinda know because I wrote (most of) the flavors code, and I also write (most of) the documentation.) -- Mathieu Arnold signature.asc Description: PGP signature
Re: What is the actual syntax used to FLAVOR ports?
Mathieu Arnold writes: > [...] > Flavors have been documented from day one. > > https://www.freebsd.org/doc/en/books/porters-handbook/flavors.html > > (I kinda know because I wrote (most of) the flavors code, and I also > write (most of) the documentation.) But, and I think that this is where this thread began, I can't find any documentation for the end user and the hints that I have found are not very discover-able. The FreeBSD Handbook section for using ports [using-ports] doesn't even contain the word "flavors". I can't find any mention in the docs of how to select a particular flavor while building a port (make FLAVOR=py27) or when installing a particular flavored pkg (e.g. py-37-s3cmd). I just discovered that a port's FreshPorts page includes a list of acceptable flavors (e.g. [py-s3cmd], [emacs]), which is super-useful. I can't find a similar command line invocation and don't see anything relevant in the `Default targets` section of bsd.port.mk. Have I missed something somewhere? g. [emacs]: https://www.freshports.org/editors/emacs/ [py-s3cmd]: https://www.freshports.org/net/py-s3cmd/ [python-flavors]: https://www.freebsd.org/doc/en/books/porters-handbook/flavors-auto-python.html [using-ports]: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Debugging build with gmake, running npm toolchain
I maintain www/gitea, and with the newest release, the build has been changed from a mostly pure Go build to a more complex setup using gmake, and including some npm-based toolchain to build CSS and JS. Right now, changing the port from USES=go:modules to USES=gmake runs into a compilation/linking error: flag provided but not defined: -fstack-protector-strong usage: link [options] main.o -B note add an ELF NT_GNU_BUILD_ID note when using ELF -E entry set entry symbol name The flag -fstack-protector-strong is not part of the Gitea code, but seems to come from the ports system. I'm having a hard time finding a build switch that prints the gmake command that is actually invoked, and information on how to customize that. The second issue is that npm install is invoked, which will most likely prevent the port to be built as a package. Is there a way to handle the download of the package-lock.json dependencies in the fetch stage? Stefan -- Stefan BethkeFon +49 151 14070811 signature.asc Description: Message signed with OpenPGP
Re: What is the actual syntax used to FLAVOR ports?
On Tue, 11 Feb 2020 09:45:53 +0100 Mathieu Arnold m...@freebsd.org said On Mon, Feb 10, 2020 at 09:02:34PM -0500, Ernie Luzar wrote: > Kevin Oberman wrote: > > On Sat, Feb 8, 2020 at 1:27 PM Chris wrote: > > > > > OK I know FLAVOR is an evolving concept. But I can not find > > > the FLAVOR documentation. Only references in the porters > > > handbook. What I think needs to be available is an entire > > > list of flavor tags for all (port) categories. > > > For example; > > > make FLAVOR=python27 returns the error use py27. > > > OK now I know how to flavor, and build python flavors. > > > But what of Perl? > > > make FLAVOR=perl2.8. Nope. How about make FLAVOR=p5-28, > > > and so it goes... > > > Does there exist a definitive list of flavors? It'd > > > also be valuable for defining defaults in make.conf(5) > > > > > > Thanks! > > > > > > --Chris > > > > > > The problem is not having a clear understanding of what a FLAVOR is and > > when it is used. > > > > FLAVORS are generally a way to deal with the problem of incompatible > > versions and Python is the poster child. Python2 and Python3 are two > > version of a VERY popular language that have significant syntax > > incompatibilities. While a program written for gcc-4.2 should work fine > > when compiled with gcc-7, it is VERY unlikely that a program written for > > Python2 will work with Python3. While the changes needed are often fairly > > straight forward, they have to be made. The result is a requirement of > > having both interpreters installed and two packages of of most Python > > libraries built from a single source. > > > > Adding FLAVORS for a port is an expensive operation and is never lightly > > approved by the ports management team as it adds a great deal of > complexity > > and both human and machine overhead. Requests to FLAVOR a port are > > carefully reviewed and will only be approved with adequate justification. > > > > In the case of Perl, no attempt to flavor it has been needed. Most Perl > > packages (p5-*) will work with any of the three available ports. In most > > cases they may be installed and continue to work across versions with no > > changes. Python (py-) ports MUST be reinstalled to move from Python2 to > > Python3. Some have not had required changes to work with Python3 made and, > > initially, almost none did. Some have now been written with no support for > > Python2. All of this has to be properly handled by the package building > > system and it is not at all trivial. > > > > As of today, I believe the only FLAVORed ports are those using emacs, > > lazarus, php, and, of course, python. By "using", I mean that the port > > Makefile includes "USE_PYTHON" or similar USE_ definitions of the other > > languages. (Yes, emacs is not a language, but elisp, the core of emacs, is > > and lazarus is an IDE for Pascal.) > > > > I'm sorry of this is not entirely clear, but I hope it helps and I hope it > > is all correct. I may have worded some of it poorly. > > -- > > Kevin Oberman, Part time kid herder and retired Network Engineer > > E-mail: rkober...@gmail.com > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > wow the above reply is not how I remember how things were envisioned when > this flavor function was first talked about. Having to get permission first > and being limited to languages was never talked about and not at all a > requirement. Thank you *very* much for the link and reply, Mathieu! I must admit to being fairly embarrassed for having missed it. Having to get permissions was never envisioned, and we will stop having it as a requirement when people stop trying to forcefully do very silly things, it will probably be relaxed when we have subpackages. It is not at all limited to languages, I have no idea where that came from. You only have to grep for '^FLAVORS=' to see that. Good tip! I think it's simply *easiest* to think of it in terms of languages, akin to DEFAULT_VERSIONS. > It was envisioned as a way to per can a set of different > defaults so a package with pre canned defaults would be auto built in the > ports system that is different from the basic defaults. ON the subject of > documentation about how to set up flavors for a port is totally lacking at > this point. You know the old saying, developers are good programmers but are > terrible at documenting their work if they do it at all. So with that in > mind do your own thing following what you see for flavored languages as a > loosely followed guide. Flavors have been documented from day one. https://www.freebsd.org/doc/en/books/porters-handbook/flavors.html (I kinda know because I wrote (most of) the flavors code, and I also write (most of) the documentation.) Given some of the replies to this topic. It might be wise for someone(tm) to write an introductory to FLAVORS in the Handbook, with perhaps a link to the FLAVORS section of the porters-handbook. Thanks again! --Chris -- Mathieu Arnold __
