> 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:

> 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.

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: