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
[email protected]
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?
_______________________________________________
Genode users mailing list
[email protected]
https://lists.genode.org/listinfo/users
