Re: math/lapack,-cblas,-blas,-docs
On 2024/05/22 19:15, Rafael Sadowski wrote: > On Wed May 22, 2024 at 07:02:13PM GMT, Jeremie Courreges-Anglas wrote: > > On Sun, May 19, 2024 at 06:48:17PM +0200, Rafael Sadowski wrote: > > > Before I go deeper into the rabbit hole I would like to ask for > > > feedback. Below you can see my idea. I would like to update lapack, > > > blas and cblas. Upstream project has decided to use cmake and build > > > everything in one. I like it because it makes the current situation > > > simple. > > > > > > My suggestion is to split this into a MULTI-PACKAGE. > > > > > > A diff speaks more than 1000 words: > > [...] > > > +BUILD_DEPENDS += devel/doxygen > > > +CONFIGURE_ARGS +=-DBUILD_MAN_DOCUMENTATION=ON > > > > The dep on doxygen creates a loop. If you really want to keep > > doxygen, which is apparently required to build the docs, then you'll > > need some trick. > > I'm happy to drop the docs otherwise I think we have to make Splash > backend support (Whatever this is) in poppler optional. Dropping doxygen docs makes a lot of sense to me.
Re: math/lapack,-cblas,-blas,-docs
On Wed May 22, 2024 at 07:02:13PM GMT, Jeremie Courreges-Anglas wrote: > On Sun, May 19, 2024 at 06:48:17PM +0200, Rafael Sadowski wrote: > > Before I go deeper into the rabbit hole I would like to ask for > > feedback. Below you can see my idea. I would like to update lapack, > > blas and cblas. Upstream project has decided to use cmake and build > > everything in one. I like it because it makes the current situation > > simple. > > > > My suggestion is to split this into a MULTI-PACKAGE. > > > > A diff speaks more than 1000 words: > [...] > > +BUILD_DEPENDS += devel/doxygen > > +CONFIGURE_ARGS += -DBUILD_MAN_DOCUMENTATION=ON > > The dep on doxygen creates a loop. If you really want to keep > doxygen, which is apparently required to build the docs, then you'll > need some trick. I'm happy to drop the docs otherwise I think we have to make Splash backend support (Whatever this is) in poppler optional. poppler-24.04.0/CMakeLists.txt option(ENABLE_BOOST "Use boost (for Splash backend performance)." ON) I just open the door someone else has to go through. > > dpb log excerpt: > -- > archivers/innoextract not built devel/boost -> math/py-numpy,python3 -> > math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> > devel/boost > astro/calcmysky not built math/eigen3 -> math/suitesparse -> math/lapack -> > devel/doxygen -> math/graphviz -> print/poppler -> devel/boost -> > math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen > astro/kstars not built math/eigen3 -> math/suitesparse -> math/lapack -> > devel/doxygen -> math/graphviz -> print/poppler -> devel/boost -> > math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen > astro/py-astropy,python3 not built math/py-numpy,python3 -> > math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> > devel/boost -> math/py-numpy,python3 > astro/py-erfa,python3 not built math/py-numpy,python3 -> math/lapack,-cblas > -> devel/doxygen -> math/graphviz -> print/poppler -> devel/boost -> > math/py-numpy,python3 > astro/py-jplephem,python3 not installable math/py-numpy,python3 -> > math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> > devel/boost -> math/py-numpy,python3 > astro/py-sgp4,python3 not installable math/py-numpy,python3 -> > math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> > devel/boost -> math/py-numpy,python3 > astro/py-skyfield,python3 not installable math/py-numpy,python3 -> > math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> > devel/boost -> math/py-numpy,python3 > astro/siril not built graphics/opencv -> math/py-numpy,python3 -> > math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> > devel/boost -> math/py-numpy,python3 > astro/stellarium not built x11/qt6/qtmultimedia -> x11/qt6/qtquick3d -> > multimedia/assimp -> devel/boost -> math/py-numpy,python3 -> > math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> > devel/boost > [snip] > -- > > -- > jca
Re: math/lapack,-cblas,-blas,-docs
On Sun, May 19, 2024 at 06:48:17PM +0200, Rafael Sadowski wrote: > Before I go deeper into the rabbit hole I would like to ask for > feedback. Below you can see my idea. I would like to update lapack, > blas and cblas. Upstream project has decided to use cmake and build > everything in one. I like it because it makes the current situation > simple. > > My suggestion is to split this into a MULTI-PACKAGE. > > A diff speaks more than 1000 words: [...] > +BUILD_DEPENDS += devel/doxygen > +CONFIGURE_ARGS +=-DBUILD_MAN_DOCUMENTATION=ON The dep on doxygen creates a loop. If you really want to keep doxygen, which is apparently required to build the docs, then you'll need some trick. dpb log excerpt: -- archivers/innoextract not built devel/boost -> math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> devel/boost astro/calcmysky not built math/eigen3 -> math/suitesparse -> math/lapack -> devel/doxygen -> math/graphviz -> print/poppler -> devel/boost -> math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen astro/kstars not built math/eigen3 -> math/suitesparse -> math/lapack -> devel/doxygen -> math/graphviz -> print/poppler -> devel/boost -> math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen astro/py-astropy,python3 not built math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> devel/boost -> math/py-numpy,python3 astro/py-erfa,python3 not built math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> devel/boost -> math/py-numpy,python3 astro/py-jplephem,python3 not installable math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> devel/boost -> math/py-numpy,python3 astro/py-sgp4,python3 not installable math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> devel/boost -> math/py-numpy,python3 astro/py-skyfield,python3 not installable math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> devel/boost -> math/py-numpy,python3 astro/siril not built graphics/opencv -> math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> devel/boost -> math/py-numpy,python3 astro/stellarium not built x11/qt6/qtmultimedia -> x11/qt6/qtquick3d -> multimedia/assimp -> devel/boost -> math/py-numpy,python3 -> math/lapack,-cblas -> devel/doxygen -> math/graphviz -> print/poppler -> devel/boost [snip] -- -- jca
Re: math/lapack,-cblas,-blas,-docs
Rafael Sadowski [2024-05-19, 18:48:17]: > Before I go deeper into the rabbit hole I would like to ask for > feedback. Below you can see my idea. I would like to update lapack, > blas and cblas. Upstream project has decided to use cmake and build > everything in one. I like it because it makes the current situation > simple. > > My suggestion is to split this into a MULTI-PACKAGE. > > A diff speaks more than 1000 words: This approach is fine with me. With the legacy build system this port is not very maintainable. I ran into some build issues last time I tried to update it, good to see that it's fine with cmake. I'll take a closer look soon.
Re: math/lapack,-cblas,-blas,-docs
On 2024/05/19 21:55, Dima Pasechnik wrote: > On 19 May 2024 20:08:43 BST, Jeremie Courreges-Anglas wrote: > >On Sun, May 19, 2024 at 06:28:58PM +0100, Dima Pasechnik wrote: > >> On Sun, May 19, 2024 at 06:48:17PM +0200, Rafael Sadowski wrote: > >> > Before I go deeper into the rabbit hole I would like to ask for > >> > feedback. Below you can see my idea. I would like to update lapack, > >> > blas and cblas. Upstream project has decided to use cmake and build > >> > everything in one. I like it because it makes the current situation > >> > simple. > >> > >> Would it make sense to use a reasonably modern egfortran, i.e. gfortran 11, > >> still supported by upstream: > >> https://gcc.gnu.org/gcc-11/ > >> over the default gfortran 8.4, which is long past its expiry date: > >> https://gcc.gnu.org/gcc-8/ > > > >One issue is that gcc-8 and gcc-11 can't be installed at the same > >time. That cannot work for bulk builds, so you'd need to switch the > >whole ports tree to gcc-11. And someone has to volunteer to handle > >that transition. > > > >Being able to install multiple versions seemingly brings less > >friction. But it also brings another set of problems (C++ ABI changes > >for examples) and I doubt that it would help much in the long run. > > > > Are there ports which depend on g++ ? (which would be insane IMHO). Loads on sparc64.
Re: math/lapack,-cblas,-blas,-docs
On 19 May 2024 20:08:43 BST, Jeremie Courreges-Anglas wrote: >On Sun, May 19, 2024 at 06:28:58PM +0100, Dima Pasechnik wrote: >> On Sun, May 19, 2024 at 06:48:17PM +0200, Rafael Sadowski wrote: >> > Before I go deeper into the rabbit hole I would like to ask for >> > feedback. Below you can see my idea. I would like to update lapack, >> > blas and cblas. Upstream project has decided to use cmake and build >> > everything in one. I like it because it makes the current situation >> > simple. >> >> Would it make sense to use a reasonably modern egfortran, i.e. gfortran 11, >> still supported by upstream: >> https://gcc.gnu.org/gcc-11/ >> over the default gfortran 8.4, which is long past its expiry date: >> https://gcc.gnu.org/gcc-8/ > >One issue is that gcc-8 and gcc-11 can't be installed at the same >time. That cannot work for bulk builds, so you'd need to switch the >whole ports tree to gcc-11. And someone has to volunteer to handle >that transition. > >Being able to install multiple versions seemingly brings less >friction. But it also brings another set of problems (C++ ABI changes >for examples) and I doubt that it would help much in the long run. > Are there ports which depend on g++ ? (which would be insane IMHO).
Re: math/lapack,-cblas,-blas,-docs
On Sun, May 19, 2024 at 06:28:58PM +0100, Dima Pasechnik wrote: > On Sun, May 19, 2024 at 06:48:17PM +0200, Rafael Sadowski wrote: > > Before I go deeper into the rabbit hole I would like to ask for > > feedback. Below you can see my idea. I would like to update lapack, > > blas and cblas. Upstream project has decided to use cmake and build > > everything in one. I like it because it makes the current situation > > simple. > > Would it make sense to use a reasonably modern egfortran, i.e. gfortran 11, > still supported by upstream: > https://gcc.gnu.org/gcc-11/ > over the default gfortran 8.4, which is long past its expiry date: > https://gcc.gnu.org/gcc-8/ One issue is that gcc-8 and gcc-11 can't be installed at the same time. That cannot work for bulk builds, so you'd need to switch the whole ports tree to gcc-11. And someone has to volunteer to handle that transition. Being able to install multiple versions seemingly brings less friction. But it also brings another set of problems (C++ ABI changes for examples) and I doubt that it would help much in the long run. -- jca
Re: math/lapack,-cblas,-blas,-docs
On Sun, May 19, 2024 at 06:48:17PM +0200, Rafael Sadowski wrote: > Before I go deeper into the rabbit hole I would like to ask for > feedback. Below you can see my idea. I would like to update lapack, > blas and cblas. Upstream project has decided to use cmake and build > everything in one. I like it because it makes the current situation > simple. Would it make sense to use a reasonably modern egfortran, i.e. gfortran 11, still supported by upstream: https://gcc.gnu.org/gcc-11/ over the default gfortran 8.4, which is long past its expiry date: https://gcc.gnu.org/gcc-8/ Dima signature.asc Description: PGP signature
