Remy Bohmer wrote:
> Hello Marc,
> 
> Thanks for looking into the patches.
> Here are a few answers to your questions:
> 
>> just call it LIBUSB_COMPAT, i'm lazy typer :)
> 
> You should not have to type that name, it is generated by Kconfig ;-)
> OK, I will change that.
> 
>>> +config LIBUSB_VERSION_COMPAT
>>> +     string
>>> +     prompt "Version number of libusb-compat"
>>> +     default "0.1.0"
>>> +     help
>>> +       Version number of the libusb compatibility layer
>>> +       First version released is 0.1.0
>> just hardcode these... see comment below in targetinstall stage
> 
> Do you mean hardcode the versionnumbers?
> I prefer a configurable version-number, because numbers may change,
> which saves a lot of patches to the tree...

on the other hand version numbers are scattered over 10th of BSP we
have. Due to the fact that a version number usually results in a
different targetinstall stage, and we don't support proper wild-cards,
it only suggests a flexibility that it doesn't have.

>>> +
>>> +endif
>>> +if !LIBUSB_COMPAT_LAYER
>>> +
>>> +config LIBUSB_VERSION
>>> +     string
>>> +     prompt "Version number of libusb"
>>> +     default "0.1.12"
>>> +     help
>>> +       libusb 0.1.12 is the latest of the 0.1 releases
>> dito
> 
> This version could be hardcoded, because it is likely that it does not
> change anymore (EOL)
> 
>>> @@ -3,6 +3,8 @@
>>>  #
>>>  # Copyright (C) 2007 by Sascha Hauer
>>>  #
>>> +# Added support for libusb-compat by Remy Bohmer
>> we have git for this...

or svn or $RCS :)

> Yeah, I know, but that comment would preventing others to blame Sascha
> if things are not working ;-)
> Can I have access somehow to the git tree? That would be easier to
> develop and provide patches.

http://git.pengutronix.de/?p=mkl/ptxdist;a=summary

> Now I download the SVN tree, make a git-tree out of it, and convert
> the changes to patches...
> Just curious, why is there an SVN tree if you are developing the tree
> with git anyway?

There is a git tree because I'm working with git, svn is still
"mainline". You can send me pull requests iy you're working with git, too.

>>> +ifdef PTXCONF_LIBUSB_COMPAT_LAYER
>>> +$(STATEDIR)/libusb.prepare: $(STATEDIR)/libusb1.install
>>> +endif
>> use a select in the corresponding .in file, like:
>>        select LIBUSB1 if LIBUSB_COMPAT
> 
> I have this:
> config LIBUSB_COMPAT_LAYER
>         bool
>         prompt "libusb-0.x compatibility layer"
>         select LIBUSB1
> 
> Isn't that the same? But that does not work very well on dependencies
> with incremental builds.

No it isn't the same.
We cannot detect that LIBUSB_COMPAT_LAYER belongs to LIBUSB and generate
a dependency from LIBUSB to LIBUSB1.

config LIBUSB
        select LIBUSB1 if LIBUSB_COMPAT

Here we have a direct connection from LIBUSB to LIBUSB1. From this
information we generate the dependencies.

> I have a lot of problems with incremental builds where zlib.h,
> libusb.h, ncurses cannot be found during building of several packages,
> where this method of adding dependencies
> seemed to be the only way to get the dependencies right.

Dependencies doesn't work that way.

> For example, try building a tree without usbutils, and than adapt the
> ptxconfig and select lsusb from the usbutils package. (or drop the
> compile stage of usbutils). The build fails badly because of missing
> dependencies.

> Adding dependencies like this to the targetinstall stage of libusb,
> zlib and so on solved that problem. I have a patch that does this
> exactly, but I guess you will not like it, but I have not found a more
> generic solution yet...)

we don't need that. :)

>>> -     @$(call install_copy, libusb, 0, 0, 0644, 
>>> $(LIBUSB_DIR)/.libs/libusb-0.1.so.4.4.4, /usr/lib/libusb-0.1.so.4.4.4 )
>>> +     @$(call install_copy, libusb, 0, 0, 0644, 
>>> $(LIBUSB_RESULTS)/.libs/libusb-0.1.so.4.4.4, /usr/lib/libusb-0.1.so.4.4.4 )
>> is this in all libusb0 and compat versions the same library version?
> 
> Yes, libusb-.0x-compat is meant to be a drop-in replacement and ABI
> compatible to 0.1.x. It has the same library versionnumbers as 0.1.12.

okay.

cheers, Marc

-- 
Pengutronix e.K.                         | Marc Kleine-Budde           |
Linux Solutions for Science and Industry | Phone: +49-231-2826-924     |
Vertretung West/Dortmund                 | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686         | http://www.pengutronix.de   |

Attachment: signature.asc
Description: OpenPGP digital signature

--
ptxdist mailing list
ptxdist@pengutronix.de

Reply via email to