Re: Debugging build with gmake, running npm toolchain

2020-02-14 Thread Willem Jan Withagen

On 13-2-2020 15:20, Stefan Bethke wrote:



Am 13.02.2020 um 14:42 schrieb Marcin Cieslak :

On Wed, 12 Feb 2020, Stefan Bethke wrote:


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?

I have some hack in my private node-sass port: 
https://github.com/saper/ports-exp/tree/master/textproc/node-sass

jrm@ has solved this in the late net-im/mastodon port by simply putting all 
JavaScript together
in one tarball: 
https://svnweb.freebsd.org/ports/head/net-im/mastodon/?pathrev=472547

https://ftfl.ca/blog/2017-05-23-mastodon-freebsd.html

The port got removed in https://svnweb.freebsd.org/ports?view=revision&revision=474751 


Thanks for the pointers!

I'm currently trying to convince upstream to package the dependencies as 
vendor-like archives (for both Go modules and npms) and deploy them alongside 
the source release archive. That would allow me to treat these as additional 
distfiles, and simply unpack them into $WRKSRC.

I'm hoping that this would make the maintenance of the port halfway reasonable.


I have the same issue in my ceph ports, where the dashboard is build 
using npm.


Tarring up the result and download that during the fetch phase is one of 
the solutions that was offered to me as well.
But then I am responsible for maintaining again another set of data to 
keep updated.
Another disadvantage of tarring is that that adds another dependency for 
the maintainer to keep.
Note that updating the tar, will require updating the port to fix the 
checksum.
(unless one really hardcore manually fetches the tar in post_fetch, 
without caring about integrity)


For now it have chosen for the following, easy way out:
    - require npm as runtime dependency
    - include the build list/json config in the package
    - explain in pkg-message how to actual let the user do it by 
him/herself.


The disadvantage of this is a large wagonload of node packages that gets 
downloaded in the code cache.
Something that is not an issue when tarring up the actual code for the 
dashboard.


--WjW



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


FreeBSD ports you maintain which are out of date

2020-02-14 Thread portscout
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
databases/postgresql-orafce | 3.4.0   | 
version_3_9_0
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Reported by:portscout!
___
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"