7602 2015-04-13 14:32:36 +0000 devtool: improve handling for recipes that point to local source next to recipe 2015-10-01 12:49:11 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 1.8 All Multiple RESOLVED FIXED Medium enhancement 2.0 1 bluelightning markus.lehtonen meta.mr.watcher meta.watcher --- --- Don't know oldest_to_newest 50267 0 bluelightning 2015-04-13 14:32:36 +0000 At the moment if you run devtool modify -x on a recipe that points directly to source files in SRC_URI (such as the makedevs recipe), it copies all files into the external source tree. It does appear that you can edit the .c file there and it will be used, however also copied over is a .patch file which is not as useful. It's not also clear to me what's supposed to happen when you then edit the original files next to the recipe when externalsrc is being used. Additionally, will devtool update-recipe update the original source file with any changes? Arguably it should. 50355 1 markus.lehtonen 2015-04-16 15:27:10 +0000 Devtool should somehow make a difference between upstream sources (unpacked from an archive or cloned SCM etc) and "packaging" files, i.e. the local files under the layer directory. I'm not sure if devtool should even work with packages like makedevs as the files can be conveniently modified directly in the layer dir, anyway(?) If we support this, we should also support "extracting" the local files to the srctree (and "updating" back to layer dir) for packages which have both an upstream source and local files, like udev. What do you think? 50356 2 bluelightning 2015-04-16 15:41:54 +0000 I'm unsure as to what to do for recipes where you have a mixture of upstream source and some local files - the question would be where should those files appear once extracted given that it still has to work when you do 'devtool modify' without -x and supply your own "pristine" source tree that doesn't have those files. (It could be that we just fall back to fetching them from their original location, which shouldn't be too hard.) At the moment it appears it does mostly work for recipes like makedevs, it just needs some fine-tuning. If practical I'd like to err on the side of having devtool work for as many recipes as possible even if in some cases you're only gaining the benefit of having the same workflow working and not much else. 50382 3 markus.lehtonen 2015-04-17 12:35:38 +0000 AFAIU, there are two packages in this regard: 1. S=${WORKDIR} (e.g. makedevs.) 2. Other packages (e.g. udev) For #1 we could just ignore/remove patches (.patch and .diff files) and not commit them into srctree. With this modification it should be fairly consistent and usable. #2 is bit more complicated. Somehow it would be nice to be able to modify the local files in the srctree in this case, too (like #1). Not least for the sake of consistency, IMO. Would it be feasible to put the local files into a subdir in the srctree ('meta', or 'localfiles' or whatever) and the trick the fetcher to fetch them from there? 50446 4 markus.lehtonen 2015-04-21 15:02:25 +0000 I'm also wondering what to do when source files are modified (i.e. makedevs.c in case of makedevs) and update-recipe is run. Should we just create a patch which is what devtool currently does? Or update the original in the layer directory? The second one is hard to accomplish because we run git format-patch to generate patches and there is no way (that I know of) to exclude files/patches. We need to run format-patch anyway because some files are handled as patches. Makedevs is a tricky (and good) example because 'COPYING' is created/modified as a patch but 'makedevs.c' is a plain source file in the layer meta data. 50448 5 markus.lehtonen 2015-04-21 15:51:05 +0000 What assumptions can we make about the git version for users using devtool? I ask because git v1.9.0 added a nice feature called "negative pathspecs" which could do exactly what I'd want. I.e. something like: $ git format-patch -- . ':!makedevs.c' for excluding changes to makedevs.c from the patches. 50450 6 bluelightning 2015-04-21 15:58:21 +0000 Well, if we are applying changes back to the recipe then I would have thought we would just replace the .c file. As far as git version is concerned, our current minimum is 1.7.8 so that might prevent us relying on that option... 50471 7 markus.lehtonen 2015-04-22 13:59:20 +0000 Ok, bad luck with the git version. I try to cook up something. So, the logic for changes would be something like: 1. If the file already exists in recipe space -> update the original source 2. Otherwise (e.g. new files, archived files etc) upload a patch 54867 8 markus.lehtonen 2015-10-01 12:49:11 +0000 The feature was merged into master in http://git.openembedded.org/openembedded-core/commit/?id=c94cf6e6e8a0645c822a708a432901dcb5ce5bf4 through http://git.openembedded.org/openembedded-core/commit/?id=b7ab82485e4514e07ab8a76e554da27ddc92e6c0