On 2014/02/20 16:33, frantisek holop wrote:
> i know this won't make me any friends on ports@
> but waf is not the root of all evil.
>
> the "waf philosophy" is to bundle it with a given project,
> to become "part of the project". that is why it does
> not "need" to be "package friendly", it is not meant
> to be used from a package. if it helps, think of it
> as waf == configure and not cmake or such. configure
> is also always bundled and nobody cares.
The thing with autoconf is, the input files are *also* bundled,
so if we need to patch them and regenerate, we can do so with ease,
and without creating the maintenance problems that often occur if
the generated files (rather than the input files) are patched.
> so the bundled version is the definite version that
> should be used. (actually the problematic projects are
> the ones that dont bundle it...)
>
> it takes a bit of getting used to, but i dont see how
> it's 'much worse' then megabytes of gnu style shell
> code and m4.
>
> you do a 'waf configure ${CONFIGURE_ARGS}' then
> 'waf build' and lastly 'waf install'. the horror.
Before doing that, you usually need to patch the wscripts so that ports
can be in control of shared library version numbers, and looking at the
wip samba4 port, also patch to fix include directory ordering,
> i am not good with shared library versioning so
> i cannot comment on that, but the build result
> should be binaries, and those can be renamed
> and copied in many ways :]
It depends how they're built, you can't always do that with shared
libraries.
> is samba4 also waf? i'll try to have a look
> when i get stable internet connection in 2 weeks
> time.
yep. Peril-sensitive glasses recommended if you look at the samba4 port.
It starts off fine, then starts to get a bit "ugh" around line 200,
then you see ".include <bsd.port.mk>" and think you're done and it wasn't
actually so bad.
Then the real horrors begin ;-)
