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 not talking about usage of noux, I am talking about build system. e.g. standard libraries can’t be build using «configure» call - while targets from repos/ports can. I am not sure that exactly noux dir is necessary, probably it could be the same in repos/world. need to check...
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
sure that can - we need to update a bit sources and try to run standard environment using configure.
will try to take a look at the `goa` project. @Norman @Jozef, do you have an opinion here?
I suspect that it run only ontop of linux
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.
As I understand, there are no such files (set/get context) in sources of libpcl, as mentioned in the docs, it can use them as interface.
Moreover, original port of libc from FreeBSD used for Genode do contain some code related to implementations of them - but it was not ported yet (as I understand because it call signal-related syscalls from asm, @norman can correct me if I am wrong. May be variable args could also be a problem).
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.
if was mentioned in my previous post: https://github.com/genodelabs/genode-world/issues/244