[asterisk-dev] Re: [svn-commits] file: branch file/zaptel-firmware r1814 - in /team/file/zaptel-firmware: ./ b...

[Kevin P. Fleming]

Tzafrir Cohen wrote:

> This is why I don't like XML files: you can't really easily merge two
> real XML files into one.

The proper way to fix this for the future is to enhance menuselect so
that it can read multiple input files.

> Duplication of information. The name "pciradio appears 3 times.
> No kernel build system (nither 2.4 nor 2.6) actually requies that. 

If you run 'make menuconfig' in the 2.6 kernel build system to turn off
a module, then there is certainly duplication of information, as
menuconfig sets a CONFIG_* variable and the relevant Kbuild file has to
translate that into module names to be built/not built.

> There is also no need to explicitly remove the .ko file: the kernel 2.6
> system does that very well

All of that means that when we run make, we will need to translate our
selections into the proper rules in the Kbuild file.

> I can't find the other subdirectory (wct4xxp) here.
> 
> I have longago suggested to simply give directories a '/' suffix and
> thereby fully integrate them. This would allow very easy overriding of
> the modules list from either configure or make.
> 
> Current makefile will automatically build those two subdirectories, no
> matter what the user chooses for xpp_usb.

And all of this is being worked on already. In fact, you are seeing some
of this work in progress. Your comments seem to indicate that you think
this commit is something that is carved in stone... it's not. Developer
branches (which this is) are for experimentation, peer review and
commenting.

Yes, you have frequently commented that you think the Zaptel build
system should be done differently (disregarding the fact that we also
have to support 2.4 kernels in many cases), but the result of your
comments has not (yet) been a usable branch with the changes made. In
the meantime, Josh and I are working on improving the build system,
trying to incorporate your suggestions where it seems to make sense to
do so.

Keep in mind also that _none_ of the XML stuff is mandatory for an end
user to deal with; the same holds for Asterisk 1.4... the user can
ignore it completely, and just run "./configure && make && make install"
and they will get the same result (or better) that they would have
gotten before we started using XML and menuselect.