Hi all

> tor> ok. while question - how to call «configure» from it? the
> main reason why I make it inside «port/noux» - it allow to call
> configure from target.mk. I am against approach to extract list
> of files and compile them. This operation need to be done every
> new version of soft to be port release… IMHO this should be as
> seamless as possible, best of all involve original build
> environment.

Noux has been declared as retired recently [1].

> I am against approach to extract list
> of files and compile them. This operation need to be done every
> new version of soft to be port release… IMHO this should be as
> seamless as possible, best of all involve original build
> environment.

You right, that would be wonderful, but I am not sure if it is possible. We
will try to take a look at the `goa` project. @Norman @Jozef, do you have an
opinion here?

> tor>
> Sorry for not knowing - but seems that libpcl is a kind of
> image processing library using boost?

I've meant this one [2], sorry for the confusion:

> 1. go runtime directly call getcontext/setcontext/makecontext
> (not call swap context, as I remember), so their semantic need
> to be emulated exactly. At least, related to «kernel» signals
> (get/setsigmask). And, important, need to create stacks for
> threads to be switched from dedicated area of Golang (not as it
> implemented in boost.context via standard heap)

Yes, as far as I know, any coroutines library has an implementation of
getcontext/setcontext/makecontext and my idea to use the existing implementation.

> 2. boost do require C++ specific initialisation which also need
> to be called during construction before C main() which is called
> from golang runtime. It could have some limitations/tricks. E.g.
> too many unnecessary C++ internal functions/code will be linked
> to the executable, and/or tricky sequence. Typically such «rich»
> library hard to split and port partially, I doubt that boost
> porting is a separate complex task tightly bounded to the
> compiler version/llvm/etc.

I agree boost is hard to split. Hopefully, they will decide to fix it in the upcoming releases [3]

> I created one single issue about golang port - may be we need
> separate ones for components to be kept in main repo (outside of
> world)
> may be it worth to move this discussion here?

Sorry, I have failed to find it.

[1] https://genode.org/documentation/release-notes/20.05#Retired_Noux_runtime_environment
[2] http://www.xmailserver.org/libpcl.html
[3] https://lists.boost.org/Archives/boost/2020/11/250354.php

Have a nice weekend!
Sergey
--
gapfruit AG
Baarerstrasse 135
6300 Zug
+41 762 444 560
sergey.platonov@gapfruit.com

On Dienstag, 15. Dezember 2020 16:48:16 CET, Alexander Tormasov wrote:
> So, far we have decided that some restructure needs to be done:
> we will move most of it to genode-world. Also, we will take a
> look at the context-related functions. Do you think porting
>
> tor> ok. while question - how to call «configure» from it? the
> main reason why I make it inside «port/noux» - it allow to call
> configure from target.mk. I am against approach to extract list
> of files and compile them. This operation need to be done every
> new version of soft to be port release… IMHO this should be as
> seamless as possible, best of all involve original build
> environment.
>
> some existing libraries, like libpcl or boost.context will do the trick?
>
> tor>
> Sorry for not knowing - but seems that libpcl is a kind of
> image processing library using boost?
>
> about boost.context. In general, I think that it will be good
> to have it ported.
> but for particular go runtime I see here 2 problems
>
> 1. go runtime directly call getcontext/setcontext/makecontext
> (not call swap context, as I remember), so their semantic need
> to be emulated exactly. At least, related to «kernel» signals
> (get/setsigmask). And, important, need to create stacks for
> threads to be switched from dedicated area of Golang (not as it
> implemented in boost.context via standard heap)
>
> 2. boost do require C++ specific initialisation which also need
> to be called during construction before C main() which is called
> from golang runtime. It could have some limitations/tricks. E.g.
> too many unnecessary C++ internal functions/code will be linked
> to the executable, and/or tricky sequence. Typically such «rich»
> library hard to split and port partially, I doubt that boost
> porting is a separate complex task tightly bounded to the
> compiler version/llvm/etc.
>
>
>>
>> @Jozef, should we create issues in the genode-world repo?
>>
> I created one single issue about golang port - may be we need
> separate ones for components to be kept in main repo (outside of
> world)
> may be it worth to move this discussion here?
>