Re: [ptxdist] [PATCH] V2 Add capability to specify version number of libusb 0.1.*
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... + +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... 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. 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? +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. 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. 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...) - @$(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. Kind Regards, Remy -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] V2 Add capability to specify version number of libusb 0.1.*
On Wed, Mar 04, 2009 at 09:49:25AM +0100, Remy Bohmer wrote: +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... Is there a reason to have more than one version in ptxdist at one time? If not, we shouldn't make it configurable, because maintenance effort explodes then. If yes, it can be done. Note that, if a new version is available, it can be changed in the .make file. But making it configurable suggests that projects may work with any possible version. @@ -3,6 +3,8 @@ # # Copyright (C) 2007 by Sascha Hauer # +# Added support for libusb-compat by Remy Bohmer we have git for this... Yeah, I know, but that comment would preventing others to blame Sascha if things are not working ;-) Then just add your copyright line below Sascha's. Can I have access somehow to the git tree? That would be easier to develop and provide patches. Marc has his own git tree and shadows the svn. http://git.pengutronix.de/?p=mkl/ptxdist;a=summary Just curious, why is there an SVN tree if you are developing the tree with git anyway? ptxdist is developed with svn since ages. git is shiny and new and has it's own class of possibilities and problems. People are free to use it, but the central repository remains svn for now. +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. Note that, if you want to generate a dependency, the packet label has to do the select, not a packet option. config FOO bool prompt foo select BAR if FOO_BAR if FOO config FOO_BAR bool prompt bar option to foo endif 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. 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. Looks like missing selects. Can you do the following: - try to identify the packet in question - ptxdist clean your project - ptxdist targetinstall only the suspicious packet It has to work without dependency problems, otherwhise there is a bug. We have a packet autobuilder to find that class of problems, but until now I didn't have time for a systematic audit. 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...) Don't add dependencies in the makefiles, they have to be done in the .in files with select statements. Note that, for example, we plan to generate ipkg dependencies from the dep tree as well, and in order to do so, we have to have all deps in the kconfig system. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] V2 Add capability to specify version number of libusb 0.1.*
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- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] V2 Add capability to specify version number of libusb 0.1.*
Hello Robert, Is there a reason to have more than one version in ptxdist at one time? If not, we shouldn't make it configurable, because maintenance effort explodes then. If yes, it can be done. Note that, if a new version is available, it can be changed in the .make file. But making it configurable suggests that projects may work with any possible version. OK, I will change it. Can I have access somehow to the git tree? That would be easier to develop and provide patches. Marc has his own git tree and shadows the svn. http://git.pengutronix.de/?p=mkl/ptxdist;a=summary Is there a clone url ? Just curious, why is there an SVN tree if you are developing the tree with git anyway? ptxdist is developed with svn since ages. git is shiny and new and has it's own class of possibilities and problems. People are free to use it, but the central repository remains svn for now. I did not ask you to move to git... I just thought it was currently the opposite around, that the svn tree was generated from git these days... My mistake. Note that, if you want to generate a dependency, the packet label has to do the select, not a packet option. config FOO bool prompt foo select BAR if FOO_BAR if FOO config FOO_BAR bool prompt bar option to foo endif Clear! Looks like missing selects. Can you do the following: - try to identify the packet in question - ptxdist clean your project - ptxdist targetinstall only the suspicious packet I will look into it, I might come up with some patches :-) Don't add dependencies in the makefiles, they have to be done in the .in files with select statements. Note that, for example, we plan to generate ipkg dependencies from the dep tree as well, and in order to do so, we have to have all deps in the kconfig system. Clear! Kind Regards, Remy -- ptxdist mailing list ptxdist@pengutronix.de
