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:
- 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.
- 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_en... [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
- 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)
- 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?