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-5555 | -- ptxdist mailing list [email protected]
