@zecke pushed 1 commit.

68c1865a87d7f4ab750bda1bc98d3588cd61ff74 Make it use the OpenSSL we built, let it find libssh2

@zecke pushed 1 commit.

4e9b6c6de51e16d7e7c65b36d7438e373cd6f039 WIP.. move libpng16 forward for real..

Hi Holger,

I have difficulties building the VM so this is not tested locally. We need to have a look at iceberg before merging it.

I've built this on Ubuntu 16.04 and haven't seen any issues with iceberg (or anything else).

HTH, Alistair

Hi Holger, I heartily agree with you that this is an important issue. In talking with @ronsaldo this morning he wrote

"The painful change is building all of these third party dependencies with cmake. And cmake is not suitable at all for doing this. I would like to remove these third party dependencies on the near future, but for doing this we need a server for holding them."

and I replied

I think the best thing to do is to a) have a directory in each build.foo* which includes the pre-built support libraries b) have a separate repository to build the support libraries c) a workflow where when a new version of a library is needed one checks out repository b) and builds, and then replaces the libraries in a) and commits. That is what I'm doing with Terf. See terf-cogvm/platforms/Cross/third-party/lib.macos32x86 & lib.macos64x64.

And he agrees.

So was soon as possible we should split the repository to create e.g. opensmalltalk-third-party and stop rebuilding third-party software unnecessarily. We do have to decide where the products live on opensmalltalk-vm. I propose that they live in build.*/third-party/lib

On Thu, 27 Jun 2019 at 03:01, Eliot Miranda notifications@github.com wrote:

@ronsaldo https://github.com/ronsaldo this morning wrote:

"need a server for holding them."

Could use github "releases" ( https://help.github.com/en/articles/creating-releases) It won't change too often so doesn't need something high volume like BinTray.

and I replied

I think the best thing to do is to a) have a directory in each build.foo* which includes the pre-built support libraries b) have a separate repository to build the support libraries

Consider having a separate mirror-repo for each third-party library.

Libraries that are github hosted can just be forked. e.g. https://github.com/freedesktop/cairo

Libraries that are git based by hosted elsewhere can be cloned and pushed to opensmalltalk-vm account with full history e.g. https://www.freetype.org/developer.html

Libraries with a git repo can just be untar'ed locally and pushed via git to opensmalltalk-vm account (I only spot checked, but didn't bump into a library not using git)

The thing I'm not clear on is whether there are inter-dependencies between third-party libraries to be kept in sync. But anyway this can be done via the library.spec files.

cheers -ben

c) a workflow where when a new version of a library is needed one checks

out repository b) and builds, and then replaces the libraries in a) and commits. That is what I'm doing with Terf. See terf-cogvm/platforms/Cross/third-party/lib.macos32x86 & lib.macos64x64.

And he agrees.

So was soon as possible we should split the repository to create e.g. opensmalltalk-third-party and stop rebuilding third-party software unnecessarily. We do have to decide where the products live on opensmalltalk-vm. I propose that they live in build.*/third-party/lib

:shipit: :shrug: