date:20200720

Dynamic MAKE_JOBS_NUMBER_LIMIT

2020-07-20 Thread bob prohaska

Is it possible to dynamically set MAKE_JOBS_NUMBER_LIMIT based on
swap usage? The idea would be to check swap usage and start new 
make jobs only when swap use is "low enough", on the Pi3 that
would be less than about 500 MB in my setup.

I've tried manually adjusting the number up during a long make
session (www/chromium) and it seemed to work, but only up. Going
from 2 to 3 got an extra c++ instance, but when the machine got
swap-bound setting it back to 2 didn't inhibit creation of new jobs..

Thanks for reading!

bob prohaska

___
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"

Compiling www/chromium on rpi3

2020-07-20 Thread bob prohaska

After considerable time www/chromium compiled with -DBATCH on an RPI3 
running r362742.  More's the wonder, it actually workswell, mostly. 
Clicking on the rightmost "controls" menu item (three dots) drops the box 
for the menu, but it never fills and disapears immediately. There are lots
of warnings and messages on the controlling terminal:

bob@www:~ % chrome
[48076:1331765248:0720/200813.457803:ERROR:edid_parser.cc(102)] Too short EDID 
data: manufacturer id
[48076:1331765248:0720/200813.525958:ERROR:browser_dm_token_storage_linux.cc(100)]
 Error: /etc/machine-id contains 0 characters (32 were expected).
[48076:1386545408:0720/200814.206727:ERROR:bus.cc(393)] Failed to connect to 
the bus: Could not parse server address: Unknown address type (examples of 
valid types are "tcp" and on UNIX "unix")
[48076:1386545408:0720/200814.208308:ERROR:bus.cc(393)] Failed to connect to 
the bus: Could not parse server address: Unknown address type (examples of 
valid types are "tcp" and on UNIX "unix")
[48076:1386545408:0720/200814.771508:ERROR:bus.cc(393)] Failed to connect to 
the bus: Could not parse server address: Unknown address type (examples of 
valid types are "tcp" and on UNIX "unix")
[48076:1386545408:0720/200814.772553:ERROR:bus.cc(393)] Failed to connect to 
the bus: Could not parse server address: Unknown address type (examples of 
valid types are "tcp" and on UNIX "unix")
^C[48076:1331765248:0720/200908.297408:ERROR:network_service_instance_impl.cc(262)]
 Network service crashed, restarting service.
[48076:1428254720:0720/200923.984849:ERROR:object_proxy.cc(632)] Failed to call 
method: org.freedesktop.DBus.Properties.Get: object_path= 
/org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.UPower was not provided by any .service files
[48076:1428254720:0720/200923.987716:ERROR:object_proxy.cc(632)] Failed to call 
method: org.freedesktop.UPower.GetDisplayDevice: object_path= 
/org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.UPower was not provided by any .service files
[48076:1428254720:0720/200923.990565:ERROR:object_proxy.cc(632)] Failed to call 
method: org.freedesktop.UPower.EnumerateDevices: object_path= 
/org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.UPower was not provided by any .service files
[48087:1331765248:0720/200924.072468:ERROR:viz_main_impl.cc(152)] Exiting GPU 
process due to errors during initialization

Both hald and dbus are enabled. Is there some other service to be turned on?

If a session is opened across the network a browser window opens but remains
blank, at least on rapsiOS. At that point it seems stuck, but responds to
control-C on the controlling terminal to kill it.

Compliments and thanks to the many folks who made this exercise work at all!

Thanks for reading,

bob prohaska




___
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"

Re: Why lang/gcc9 depends native-binutils ?

2020-07-20 Thread Steve Kargl

On Tue, Jul 21, 2020 at 11:33:13AM +0900, KIRIYAMA Kazuhiko wrote:
> 
> lang/gcc9 depends devel/binutils with FLAVOR=native, so gcc9
> compilation stopped at devel/binutils. Why lang/gcc9 depends
> native-binutils ?
> 

Just a guess.  LTO.

-- 
Steve
___
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"

Why lang/gcc9 depends native-binutils ?

2020-07-20 Thread KIRIYAMA Kazuhiko

Hi, all

lang/gcc9 depends devel/binutils with FLAVOR=native, so gcc9
compilation stopped at devel/binutils. Why lang/gcc9 depends
native-binutils ?

checking whether strstr is declared... yes
checking whether vsnprintf is declared... config.status: creating Makefile
yes
checking iconv.h usability... config.status: creating testsuite/Makefile
config.status: creating config.h
config.status: executing default commands
yes
checking iconv.h presence... yes
checking for iconv.h... yes
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking how to link with libiconv... /usr/local/lib/libiconv.so -Wl,-rpath 
-Wl,/usr/local/lib
checking for iconv declaration... 
 extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, 
char * *outbuf, size_t *outbytesleft);
*** BFD does not support target native-unknown-freebsd13.0.
*** Look in bfd/config.bfd for supported targets.
gmake[3]: *** [Makefile:3563: configure-binutils] Error 1
gmake[3]: Leaving directory 
'/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1'
gmake[2]: *** [Makefile:851: all] Error 2
gmake[2]: Leaving directory 
'/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/devel/binutils
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/gcc9


My machine environments are as folows:

root@jdtpkxb:~ # uname -a
FreeBSD jdtpkxb 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362853M: Wed Jul 15 
23:46:55 JST 2020 root@msrvkxb:/usr/obj/usr/src/amd64.amd64/sys/XIJ  amd64
root@jdtpkxb:~ # svnlite info /usr/ports
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: http://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: http://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 542063
Node Kind: directory
Schedule: normal
Last Changed Author: glewis
Last Changed Rev: 542063
Last Changed Date: 2020-07-12 11:13:27 +0900 (Sun, 12 Jul 2020)

root@jdtpkxb:~ # 


Best regards.
---
Kazuhiko Kiriyama 
___
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"

Re: devel/libffi build broken for head -r363123 32-bit powerpc contexts (poudriere bulk): error: __int128 is not supported on this target

2020-07-20 Thread Mark Millard via freebsd-ports




On 2020-Jul-20, at 16:13, Piotr Kubaj  wrote:
> 
> Thanks for your report. I'm currently testing whether powerpc(64) on
> 12.1 and head can build with this patch
> https://github.com/libffi/libffi/commit/01a75ed76ea7e57f1b7a5c183e2b1e890e6aa0fd.patch

FYI: I did the powerpc64 bulk build first and it had
no problems. As far as libffi goes, __int128 exists for
powerpc64. I'm not implying that __int128 should be
used for powerpc64.

I'll note that, depending on where/how float128 is
used,

typedef char float128[16] __attribute__((aligned(16)));

use as float128 might decay to a pointer in some contexts,
unlike what __float128 or __int128 would have done.


> On 20-07-20 15:27:01, Mark Millard wrote:
>> This resulted in: Failed: 1   Skipped: 181
>> 
>> # poudriere jail -l
>> JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   PATH
>> FBSDpowerpc   13.0-CURRENT powerpc   null   2019-12-31 01:21:28 
>> /usr/obj/DESTDIRs/clang-powerpc-installworld-poud
>> FBSDpowerpc64 13.0-CURRENT powerpc.powerpc64 null   2020-01-01 15:22:36 
>> /usr/obj/DESTDIRs/clang-powerpc64-installworld-poud
>> 
>> # svnlite info /usr/ports/
>> Path: /usr/ports
>> Working Copy Root Path: /usr/ports
>> URL: svn://svn.freebsd.org/ports/head
>> Relative URL: ^/head
>> Repository Root: svn://svn.freebsd.org/ports
>> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
>> Revision: 542111
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: vanilla
>> Last Changed Rev: 542111
>> Last Changed Date: 2020-07-12 21:32:18 -0700 (Sun, 12 Jul 2020)
>> 
>> That gets the errors:
>> 
>> --- src/powerpc/ffi.lo ---
>> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
>> -I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
>> -fexceptions -MT src/powerpc/ffi.lo -MD -MP -MF src/powerpc/.deps/ffi.Tpo -c 
>> ../src/powerpc/ffi.c  -fPIC -DPIC -o src/powerpc/.libs/ffi.o
>> --- src/powerpc/ffi_sysv.lo ---
>> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
>> -I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
>> -fexceptions -MT src/powerpc/ffi_sysv.lo -MD -MP -MF 
>> src/powerpc/.deps/ffi_sysv.Tpo -c ../src/powerpc/ffi_sysv.c  -fPIC -DPIC -o 
>> src/powerpc/.libs/ffi_sysv.o
>> --- src/powerpc/ffi.lo ---
>> In file included from ../src/powerpc/ffi.c:33:
>> ../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on this 
>> target
>> typedef __int128 float128;
>>   ^
>> 1 error generated.
>> --- src/powerpc/ffi_sysv.lo ---
>> In file included from ../src/powerpc/ffi_sysv.c:35:
>> ../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on this 
>> target
>> typedef __int128 float128;
>>   ^
>> 1 error generated.
>> --- src/powerpc/sysv.lo ---
>> 
>> For reference:
>> 
>> =>> Building devel/libffi
>> build started at Mon Jul 20 14:47:19 PDT 2020
>> port directory: /usr/ports/devel/libffi
>> package name: libffi-3.3
>> building for: FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT powerpc
>> maintained by: zeis...@freebsd.org
>> Makefile ident:  $FreeBSD: head/devel/libffi/Makefile 541239 2020-07-04 
>> 22:15:48Z pkubaj $
>> Poudriere version: 3.3.99.20200326
>> Host OSVERSION: 1300101
>> Jail OSVERSION: 1300101
>> . . .
>>  /usr/ports/Mk/Scripts/ports_env.sh 
>> _CCVERSION_921dbbb2=FreeBSD clang version 10.0.1 
>> (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
>> Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: 
>> /usr/bin
>> _ALTCCVERSION_921dbbb2=none
>> _CXXINTERNAL_acaad9ca=FreeBSD clang version 10.0.1 
>> (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
>> Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: 
>> /usr/bin "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" 
>> "/libexec/ld-elf.so.1" "--enable-new-dtags" "-m" "elf32ppc_fbsd" "-o" 
>> "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" 
>> "-L/usr/lib" "/dev/null" "-lc++" "-lm" "-lgcc" "--as-needed" "-lgcc_s" 
>> "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
>> "/usr/lib/crtend.o" "/usr/lib/crtn.o"
>> . . .

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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"

devel/libffi build broken for head -r363123 32-bit powerpc contexts (poudriere bulk): error: __int128 is not supported on this target

2020-07-20 Thread Mark Millard via freebsd-ports

This resulted in: Failed: 1   Skipped: 181

# poudriere jail -l
JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   PATH
FBSDpowerpc   13.0-CURRENT powerpc   null   2019-12-31 01:21:28 
/usr/obj/DESTDIRs/clang-powerpc-installworld-poud
FBSDpowerpc64 13.0-CURRENT powerpc.powerpc64 null   2020-01-01 15:22:36 
/usr/obj/DESTDIRs/clang-powerpc64-installworld-poud

# svnlite info /usr/ports/
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: svn://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 542111
Node Kind: directory
Schedule: normal
Last Changed Author: vanilla
Last Changed Rev: 542111
Last Changed Date: 2020-07-12 21:32:18 -0700 (Sun, 12 Jul 2020)

That gets the errors:

--- src/powerpc/ffi.lo ---
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
-I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
-fexceptions -MT src/powerpc/ffi.lo -MD -MP -MF src/powerpc/.deps/ffi.Tpo -c 
../src/powerpc/ffi.c  -fPIC -DPIC -o src/powerpc/.libs/ffi.o
--- src/powerpc/ffi_sysv.lo ---
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
-I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
-fexceptions -MT src/powerpc/ffi_sysv.lo -MD -MP -MF 
src/powerpc/.deps/ffi_sysv.Tpo -c ../src/powerpc/ffi_sysv.c  -fPIC -DPIC -o 
src/powerpc/.libs/ffi_sysv.o
--- src/powerpc/ffi.lo ---
In file included from ../src/powerpc/ffi.c:33:
../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on this 
target
typedef __int128 float128;
^
1 error generated.
--- src/powerpc/ffi_sysv.lo ---
In file included from ../src/powerpc/ffi_sysv.c:35:
../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on this 
target
typedef __int128 float128;
^
1 error generated.
--- src/powerpc/sysv.lo ---

For reference:

=>> Building devel/libffi
build started at Mon Jul 20 14:47:19 PDT 2020
port directory: /usr/ports/devel/libffi
package name: libffi-3.3
building for: FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT powerpc
maintained by: zeis...@freebsd.org
Makefile ident:  $FreeBSD: head/devel/libffi/Makefile 541239 2020-07-04 
22:15:48Z pkubaj $
Poudriere version: 3.3.99.20200326
Host OSVERSION: 1300101
Jail OSVERSION: 1300101
. . .
 /usr/ports/Mk/Scripts/ports_env.sh 
_CCVERSION_921dbbb2=FreeBSD clang version 10.0.1 
(g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin
_ALTCCVERSION_921dbbb2=none
_CXXINTERNAL_acaad9ca=FreeBSD clang version 10.0.1 
(g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin 
"/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" 
"--enable-new-dtags" "-m" "elf32ppc_fbsd" "-o" "a.out" "/usr/lib/crt1.o" 
"/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "/dev/null" "-lc++" "-lm" 
"-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" 
"-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o"
. . .

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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"

textproc/cmark conflict with llvm80 doc build

2020-07-20 Thread Xavier Humbert

Hello,

Because of :

> DOCS_BUILD_DEPENDS= ${PY_SPHINX} \
>    
> ${PYTHON_PKGNAMEPREFIX}recommonmark>=0.0.20180530:textproc/py-recommonmark@${PY_FLAVOR}

devel/llvm80 cannot build its doc, if on of these ports is installed :

> [root@numenor ports]# find . -name Makefile -exec grep -H
> 'textproc/cmark'  {} \;
> ./multimedia/mkvtoolnix/Makefile:QT5_LIB_DEPENDS=  
> libcmark.so:textproc/cmark
> ./textproc/cmark/Makefile:# $FreeBSD: head/textproc/cmark/Makefile
> 498404 2019-04-08 18:10:11Z tobik $
> ./graphics/aseprite/Makefile:  
> libcmark.so:textproc/cmark \
> ./net-im/nheko/Makefile:    libcmark.so:textproc/cmark \
> ./net-im/spectral/Makefile: libcmark.so:textproc/cmark
> ./net-im/talkatu/Makefile:  libcmark.so:textproc/cmark

textproc/py-recommonmark depends on textproc/py-CommonMark, which
conflits with textproc/cmark

Regards,

Xavier

-- 
Xavier HUMBERT - Unix/Win/MacOSX Sysadmin/Network Engineer

___
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"

Can't compile rust-cbindgen

2020-07-20 Thread George Mitchell

Running on 11.3-RELEASE-p11, amd64, ports tree at 542641 (head branch).
For some reason, firefox depends on devel/rust-cbindgen.  I don't know
what that is, but it fails thus:

===>  Configuring for rust-cbindgen-0.14.3_1
thread 'main' panicked at 'couldn't initialize the libgit2 library: -1,
error: could not initialize openssl: error:1410D0B9:SSL
routines:SSL_CTX_set_cipher_list:no cipher match',
/usr/ports/lang/rust/work/rustc-1.45.0-src/vendor/libgit2-sys/lib.rs:3672:9
stack backtrace:
   0: ::fmt
   1: core::fmt::write
   2: 
   3: 
   4: 
   5: std::panicking::rust_panic_with_hook
   6: rust_begin_unwind
   7: std::panicking::begin_panic_fmt
   8: 
   9: std::sync::once::Once::call_inner
  10: libgit2_sys::init
  11: git2::config::Config::open_default
  12: 
  13: cargo::ops::registry::needs_custom_http_transport
  14: 
  15: 
  16: 
  17: std::rt::lang_start_internal
  18: 
  19: 
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
verbose backtrace.
*** Error code 101

Stop.
make: stopped in /usr/ports/devel/rust-cbindgen

===>>> make build failed for devel/rust-cbindgen
===>>> Aborting update


I recently had to change my ssl default from base to openssl to be
able to compile Qt5, but the above failure occurs whether I specify
DEFAULT_VERSIONS+=ssl=openssl or not.  Any clues?  -- George



signature.asc
Description: OpenPGP digital signature

Autogenerated versus handmade distributions from Github (possible new section to PHB)

2020-07-20 Thread Sergei Vyshenski

Hi,
Please comment.
Regards, Sergei
=
See PDF version:
https://drive.google.com/file/d/1ly9ylKJehzcqXxy3NhqN3Pywy0iqZwn9/view?usp=sharing

The text below is being offered for discussion as a candidate for a new
section of PHB, which could be placed after the existing section"5.17.
How to Use USE_GITHUB with Git Submodules?"

Writing of this text has been advised by Adam Weinberger
(adamw@):

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221634

and is based on posts by

Yasuhiro KIMURA (yasu at utahime.org):

https://lists.freebsd.org/pipermail/freebsd-ports/2017-December/111758.html

Mathieu Arnold (mat@):

https://lists.freebsd.org/pipermail/freebsd-ports/2017-December/111759.html

and Sergei Vyshenski (svysh.fbsd at gmail.com):

https://lists.freebsd.org/pipermail/freebsd-ports/2017-December/111753.html

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221634

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247459 (this one has
status: open)

=== A proposed new section of PHB starts here ===

*Autogenerated versus handmade distributions from Github*

*A-distributions*

USE_GITHUB triggers a nice feature of automatic distribution generating,
which is provided by the Github infrastructure. Upon user request it
automatically generates distribution archive (aka git archive or source
code archive or tarball) from the master branch of a specified project.
It also accepts wanted format (tgz, zip etc) and wanted tag (commit
number) of the master branch. Author of the project could label some
commit numbers with version numbers, thus performing version release.
Version numbers are published on a special web pages like:

https://github.com/openxpki/openxpki/tags

https://github.com/openxpki/openxpki/releases

Let us call such automatically (dynamically) generated distributions
"A-distributions". A-distributions do not exist on the Github portal.
They are generated upon user request. This request can come in two ways:

1)Click on an URL (shown on the Web page) like this:
https://github.com/openxpki/openxpki/archive/v3.6.1.tar.gz
Note a keyword "archive" in this type of URL.

2)Through USE_GITHUB the same file is accessible like this:
https://codeload.github.com/openxpki/openxpki/tar.gz/v3.6.1?dummy=/openxpki-openxpki-v3.6.1_GH0.tar.gz
Note a keyword "codeload" in this type of URL.

Both these URLs are virtual ones in a sense that the referenced file
actually does not exist, and is generated only upon user request.

*H-distributions*

Sometime getting of an A-distribution could place a user in a difficult
position. For illustration consider two such cases: 1) cyclic
dependencies and 2) excessive complexity.

1)Project P is called to have a cyclic dependency, if project P depends
on project P1, which in turn depends on project P.
In the simplest case of cyclic dependency, project P can depend on
itself (autodependency). Imagine that project P is dedicated to building
a library P_L, which is meant for text processing. Usually author of
such a project P illustrates use of the library P_L by employing this
library while building documentation for the same project P.
Straightforward porting of the project P for FreeBSD will bring ports
infrastructure on halt with complaint about not installed library P_L,
which is needed to build documentation, which in turn is part of the
project P.

2)Project P is called to have excessive complexity, if a tiny (and not
essential) part of it requires huge amounts of dependencies. Imagine
that a project uses a high-level workflow language to describe logic of
some complex business process. This project provides docs and examples,
where workflow language is used as a source for graphical visualization.
Then building this docs and examples would require tons of other
packages and would spend much more time that the all the rest of the
project P.

Autodependency mentioned on points 1 above could be avoided in two ways:

* *Porter's way:*Porter can split a port for the project P into two
ports: P_library and P_doc, where port P_doc depends on port P_library.
* *Author's way:*Author of the project P could prepare a documentation
in a form, which does not require further use of library P_L. To
achieve this, he makes use of the library P_L, which is available on
his personal host anyway. Then author by hand prepares a
distribution, which contains sources for building the library P_L,
and pre-built documentation in a ready-to-use form. Let us call such
distributions "H-distributions".

Example of project with autodependency is a Github project
libexpat/libexpat, which is ported to FreeBSD as port textproc/expat2
with use of H-distribution.

Excessive complexity mentioned in point 2 above could be avoided in the
Author's way as follows. Author pre-builds docs and examples with fancy
pictures himself. Then au

Dynamic MAKE_JOBS_NUMBER_LIMIT

Compiling www/chromium on rpi3

Re: Why lang/gcc9 depends native-binutils ?

Why lang/gcc9 depends native-binutils ?

Re: devel/libffi build broken for head -r363123 32-bit powerpc contexts (poudriere bulk): error: __int128 is not supported on this target

devel/libffi build broken for head -r363123 32-bit powerpc contexts (poudriere bulk): error: __int128 is not supported on this target

textproc/cmark conflict with llvm80 doc build

Can't compile rust-cbindgen

Autogenerated versus handmade distributions from Github (possible new section to PHB)

9 matches

Site Navigation

Mail list logo

Footer information