Hi Trevor, Thanks for your feedback. Indeed only a day after pressing send it dawned to me that indeed you need to pass something like PREFIX or DESTDIR. (actually maybe it would be better if PREFIX or DESTDIR or so is not needed; probably this means running do_install in a chrooted environment; I cannot judge the complexity and implications of that right now, but that is quite a drastical change).
I came to this proposal since often projects for embedded devices have additional specific/private recipes holding the actual core application of the embedded device. Aim is to make creating a recipe as simple as possible. It seemed somewhat weird that one needs to write a do_install, but no do_compile. Maybe a better solution for us is to have our own specific class which provide the do_install Best regards, Frans 2013/2/10 Trevor Woerner <twoer...@gmail.com> > Hi Frans, > > On Fri, Feb 8, 2013 at 9:24 AM, Frans Meulenbroeks > <fransmeulenbro...@gmail.com> wrote: > > There is also a default base_do_install() that is empty. > > Wouldn't it be more logical if the base_do_install would read: > > > > Currently people using only base, need to add a do_install to their > recipe > > but no do_compile (which is somewhat odd; if there is a makefile it seems > > logical to use it for install too). > > In my experience when someone manually generates a Makefile for their > project by hand it always includes an 'all' or default target but > almost never includes a 'check', 'uninstall', or 'install' target; > there's a 50/50 chance of it having a 'clean' target of some sort. So > I don't think it's a stretch for the Yocto system to assume a Makefile > doesn't contain an 'install' target. But even if you get lucky and it > does include an 'install' target, what are the chances it has been > designed to properly handle a 'PREFIX' or 'DESTDIR'? > > So you're starting with a low probability that a hand-generated > Makefile includes an 'install' target, then coupling that with an even > lower probability that it can flexibly install somewhere other than > /usr/bin or /bin. Yocto's behaviour seems reasonable to me :-) > > Best regards, > Trevor >
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
