07-12-2017 10:28 PM
Because I recently upgraded Vivado to 2017.1, I also had to upgrade Petalinux to 2017.1 (from 2015.4). Now I am finding that the structure of apps and libs in Petalinux has changed and I can't just copy over my source and rebuild. For one thing, all relative paths for include files and libs in my project will need to be redone. That's not a big deal, but it appears (from a forum message and from experience) that I also need to enter all of the source code filenames, including the h files, in the app's bb file before my app will build.
Since the makefile already specifies the source files, having to enter them again seems primitive - is this really necessary?
More importantly, is there an AR or UG that describes the current Petalinux project tree structure and a best practices way of migrating from the older tree structure?
I feel like I'm missing something.
07-17-2017 05:09 AM
Can you mention your current version of petalinux?
There is no much structural changes from v2016.4 to v2017 but there is huge changes compared to prior versions of v2016.4.
you have to take care of your files which need to be mentioned in .bb files in newer version of petalinux.
07-18-2017 07:14 AM
...I also need to enter all of the source code filenames, including the h files, in the app's bb file before my app will build. Since the makefile already specifies the source files, having to enter them again seems primitive - is this really necessary?
It is quite obnoxious, I agree.
The reason is that the build system needs a standard way to know when a package needs to be rebuilt. It does that by tracking checksums of source files.
If you look through the petalinux install directory under components/yocto/source, you'll find that most of the system .bb files (recipes) do not list all the files. Instead, most packages install from an archive (tar.gz, etc) or from a code repository (git). In those cases, the recipe just needs to list the single file/location, rather than all the contents.
So you get to pick your poison. Either having to maintain that list of all source code files at the top of the recipe, or modifying your workflow to tar up your source or check it into a repo before petalinux builds it.
I prefer the git method, personally. The repository can be changed to a local one, and you can use any branch or commit ID you want. Once the code changes become infrequent, you can switch to using packaged code. In either case, it's worthwhile to make a new recipe for each revision, which will force petalinux to rebuild it.
07-18-2017 03:23 PM
Thanks for the info. I migrated from 2015.4 so I got the huge changes. I'm now in the autoconf world and builds are working.
07-18-2017 03:34 PM
Thanks for the details jeffsimpson. The git method sounds like the most robust one. I'm using autoconf now (created project with autoconf template and things are working). This particular petalinux upgrade from 2015.4 to 2017.1 was an unexpected and time-consuming distraction from the schedule, but having worked in the Xilinx world for about a year now (coming from Altera) the land mines are to be expected.