I was hoping someone who knows more then I do about this stuff would have commented, but I guess not.
The expectation, as I understand it, is that what you are asking for is more or less what we want to provide. The way we do a lot of this internally is via a custom (internal) layer that has a bbappend for one or more recipes and then overrides the SRC_URI, as well as specifies the checksums. I know there is a partial mechanism to select this stuff via configurations, but that doesn't solve the checksum issue of course. I'd be happy to review (and likely include) a patch that enables this functionality if you are interesting in generating something. (More below) On 12/1/20 7:31 AM, [email protected] wrote: > for a while i've been wanting to be able to use my local.conf to point to > different .xsa files for quick testing without having to make changes to the > meta-xilinx-tools external-hdf.bbappend i have in my board bsp layer.... > problem is specifying the SRC_URI checksums (the files are kept in > artifactory, > http:// wget fetcher). > basically i've created a .bbappend to be able to specify the pathname on the > server to fetch the .xsa file, part of the path includes the date, so i > construct the pathname and the downloaded image as: > HDF_DATE ?= "<the current version that is good>" > PV = "${HDF_DATE}" > HDF_BASE = "http://"; > HDF_NAME ?= "<the filename>" > HDF_PATH ?= "<the server>/<the path>/${PV}/${HDF_NAME}.<the extension> > SRC_URI = "${HDF_BASE}${HDF_PATH};downloadfilename=${HDF_NAME}_${PV}.<the > extension> Ya, this is a reasonable use-case. One of the things we're working on is having two different workflows through the system. Once that uses XSCT for a full system flow design, and one that just pulls output artifacts (xsa, device trees, etc) from a static location. I'm currently thinking that for default machines, we would want to provide pre-generated files and use an approach like that, specified inside of the MACHINE files themselves. Then if a user enabled meta-xilinx-tools (and XSCT support) then it would switch to the more end-to-end generation. (Sorry, I might not be using all of the right terms here.. but hopefully you get the idea.) > this fetches the file to the DL_DIR with a unique name (they all have the same > basename on the server), and the WORKDIR is uniquely named by PV. in my > local.conf i can specify the HDF_DATE to pick a particular design. > > the issue is that SRC_URI[md5sum/sha256sum] needs to be provided. what i > thought should have worked is specifying a weak assignment for the checksums > in > the recipe for the default weak assignment (HDF_DATE) of the current design: > SRC_URI[md5sum] ?= "<the sum>" > SRC_URI[sha256sum] ?= "<the longer sum>" > > and then in the local.conf file override the checksums: > HDF_DATE = "2020.11.18" > SRC_URI_pn-external-hdf[md5sum] = "<md5sum for 2020.11.18 design>" > SRC_URI_pn-external-hdf[sha256sum] = "<long sum for 2020.11.18>" Unfortunately you can't override 'flags' like this, so your approach below... > this doesn't seem to work correctly..... 'bitbake virtual/hdf' evaluates the > checksums set weakly in the recipe bbappend as the sums when fetching rather > than using the package name override in the conf file..... i can't remove the > SRC_URI checksums in the recipe because they apparently need to be set during > the recipe parsing to start with vs being set at variable evaluation > time....(not sure if i'm using the correct terminology)... > > i was finally able to solve it with a bit of kludgery, but wondered if there > was > perhaps a better way that i'm missing. the way i solved it was to specify in > the recipe bbappend: > SRC_URI[md5sum] ?= "<something>" > SRC_URI[sha256sum] ?= "<something longer>" > HDF_MD5 ?= "<something>" > HDF_256 ?= "<something longer>" ... the above should work without needing the anonymous python below ... > python () { > d.setVarFlag('SRC_URI','md5sum',d.getVar("HDF_MD5")) > d.setVarFlag('SRC_URI','sha256sum',d.getVar("HDF_256")) > } > > now in local.conf: > HDF_DATE = "<some date>" > HDF_MD5 = "<checksum>" > HDF_256 = "<longsum>" Yes, I think this makes a lot of sense to do. We specify the defaults in the original recipe, and then allow via configuration or bbappend it being overwritten. > and everything works. default design is pulled from server in the absence of > the variables in the local.conf, and the local.conf variables are correctly > used > as the 'current' version when desired. > > is there some other mechanism that should work? it seems kinda kludgy this > way. took me the day to figure out, i'm satisfied for now because it removes > some manual processing when a new design is dropped on me for testing but was > looking for something more elegant (seeming). As far as I know what you did is reasonable, but it seems like something we could include in the layer itself to actually improve it (without impacting any other existing users.) Thanks! --Mark > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4785): https://lists.yoctoproject.org/g/meta-xilinx/message/4785 Mute This Topic: https://lists.yoctoproject.org/mt/78632911/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
