[bind10-dev] Running individual applications from the source tree

[zhanglikun]

> 
> There is a ticket that Jeremy is working on right now, #158:
> 
> https://bind10.isc.org/ticket/158
> 
> There was a problem with the magic script we use to run the boss from
> the source tree itself, now fixed.
> 
> My question is, do we need to be able to run other applications directly
> from the source tree (like xfrin in this case)? I have never done so,
> but I can see how it might be useful for development or testing.
> 
> My goal here is not to waste time doing work that we don't find useful.
> Do people think we should maintain this capability? If so, I'll ask
> Jeremy to continue with this ticket. Otherwise, we can remove the
> various run_foo.sh scripts.

Just append some jabber chat on this topic to promote more ideas

15:06:04jreed:  Is it really important to run all of bind10 from source
tree? Adding special cases for socket files, zone databases, spec files, etc
seems like overkill to do something that would not be done in real life.
15:07:21jreed:  My wife just bought a netbook (Asus Aspire One).
15:45:28each:  I think it's easier to develop when you can run in situ.
also, I can't recall ever having run an open source product without having
tested it in the build directory before running make install
15:46:41each:  I wonder how hard it would be to rethink the design so we
don't need special cases everywhere
16:05:39:  jreedI just can't think of any any software that provides
wrappers, workarounds, environment variables, etc that allow them to be ran
in source directory.

17:36:40jinmeiI:  also think it may be useful if we can run a particular
instance of b10 programs (auth, xfrin/out, etc) without being invoked from
the boss.
17:37:17jinmei:  that will help a larger level of unit tests, will make it
easier to run it under the source tree, and will be convenient if you want
to run it on the debugger.
17:38:33jinmei:  right now the real hard dependency is the connection with
msgq, but e.g. the auth server could load a default data source and handle
queries without communicating with others via the msgq.
17:39:26jinmei:  so we might make the msgq connection optional (mainly for
debugging purpose).
17:39:58each:   I like that idea.
17:40:00jinmei:  (but when/if we introduce a socket creater process, it may
become more difficult)
17:40:44each:  perhaps separate processes could be limited to running as
root (and making their own sockets) or using nonprivileged ports
17:41:41jinmei:  yeah, so by carefully designing the interface we can
abstract that part (either by opening it in the unsafe mode by itself or by
getting it via the socket creator, all under the hood)

Zhang Likun