Hi, On Wed, Mar 11, 2015 at 10:42 AM, Paul Eggleton <paul.eggle...@linux.intel.com> wrote: > I would advise against simply setting S as the build system normally thinks it > is in control of that directory and may under certain circumstances delete it, > which probably won't be what you want. > > We do have a proper mechanism for this kind of thing - the externalsrc class. > Here is a section of the manual that describes how to use it: > > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source > > Generally though externalsrc is designed for temporary usage; long term > I'd recommend you keep your metadata and source code separate and > have the recipe(s) fetch the source in the normal manner. >
I read the first email as that the problem was simple having multiple modules in the git-repo, I missed that the recipes and actual code was in the same git. You are right that setting S to point somewhere outside of ${WORKDIR} is unsafe. Cheers, Erik > Cheers, > Paul > > On Wednesday 11 March 2015 09:34:30 Erik Botö wrote: >> I think you should set S to whatever directory that contains your >> source, it has a default to ${WORKDIR}/${PN}-${PV} if I remember >> correctly. >> >> So S = "${WORKDIR}/${PN}" should work if the recipe is named the same >> as the subdir in git, otherwise just set it explicitly using e.g. S = >> "${WORKDIR}/module_a" >> >> Side note: Your example uses an underscore, which means that a and b >> would be interpreted as versions, which is probably not intended. See >> http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#new-recipe-s >> toring-and-naming-the-recipe >> >> Cheers, >> Erik >> >> On Mon, Mar 9, 2015 at 4:37 PM, Koehler, Yannick (HP Networking) >> >> <yannick.koeh...@hp.com> wrote: >> > Hi, >> > >> > I need some help regarding this since I cannot find out how to achieve >> > this. I have a git repo with a lot of code splitted in module, such as: >> > /.git >> > /module_a >> > /module_b >> > >> > Etc... >> > >> > I want to compile those modules using a bitbake recipe within yocto so I >> > created the following tree structure: >> > /.git >> > /module_a >> > /module_b >> > /poky >> > >> > /meta-modules >> > >> > /recipes-<category> >> > >> > /module_a >> > >> > module_a.bb >> > >> > /recipes-<category> >> > >> > /module_b >> > >> > module_b.bb >> > >> > So far so good, but now I am having issue with unpack/compile step, my >> > modules are make-based (not autotools and not CMake). So I used >> > EXTRA_OEMAKE to get them to use the proper target toolchain. Problem >> > lies with the SRC_URI, my files from module_a gets copied into $WORKDIR >> > and not into $S, as such the compile step failed. I understand that >> > SRC_URI is not really the proper usage in such situation, appears to be >> > meant to retrieve external packages and some files here and there, >> > mostly patches. Even thought all my modules are within a git repo, I >> > do not want to extract the full repo for each modules either. >> > >> > I am now looking into writing my own unpack function to move my code >> > under S manually, but I was wondering if yocto had something to support >> > this model and I simply missed it or if writing a custom unpack is the >> > appropriate solution (likely I'll have to create a class so that all my >> > modules use the same unpack behavior).> >> > Yannick Koehler >> > -- >> > _______________________________________________ >> > yocto mailing list >> > yocto@yoctoproject.org >> > https://lists.yoctoproject.org/listinfo/yocto > > -- > > Paul Eggleton > Intel Open Source Technology Centre -- Erik Botö M.Sc.E.E. SENIOR SOFTWARE ENGINEER Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden Mobile: +46 (0)768 817 203 E-Mail: erik.b...@pelagicore.com PELAGICORE Experience Change -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto