Hi there, On Wed, May 24, 2023 at 12:34:21PM +0200, Alexander Dahl wrote: > Hello Jookia, > > as a long term user not affiliated with pengutronix I have some comments > which > might help. See below. > > Am Mittwoch, 17. Mai 2023, 18:11:31 CEST schrieb Jookia: > > Hello ptxdist friends, > > > > I spent some time over the past few days trying to use ptxdist and > > documenting all the pain I hit in the process. This isn't a criticism > > more just anecdotal data of my experience. Hopefully it's useful to > > smooth down some rough edges. > > > > I'm going to write this up in a psuedo-markdown format in sections, > > sorry if that breaks anyone's workflow. > > > > > > Documentation > > ------------- > > > > First up: Documentation is quite good aside from the 'Getting a working > > environment' section. I will be focusing on this today since I think it's > > probably the most critical problem with ptxdist at the moment: I expect > > that by the end of following this chapter I should have a bootable image > > of some kind and commands for using it, such as with qemu. > > > > The first issue is that I'm told to downloaded files, but I'm not linked > > to them, quoting: > > > > ptxdist-2023.05.0.tar.bz2 > > OSELAS.BSP-Pengutronix-Example.tar.bz2 (or a similar source) > > ptxdist-2019.09.0.tar.bz2 > > OSELAS.Toolchain-2019.09.1.tar.bz2 > > > > The OSELAS website is linked as ptxdist.org that doesn't mention OSELAS > > at all. There is a link to the toolchain but it's a different version. > > I managed to find a BSP for 'Generic' but it's 9 years old. > > +1 > > That has to be improved. There's no easy accessible single platform example > BSP to get your feet wet, and DistroKit is nice for supporting some quite > common SBCs, but is already quite complicated.
would something like this be sufficient? diff --git a/doc/environment.rst b/doc/environment.rst index 18aecec4e..670f86a48 100644 --- a/doc/environment.rst +++ b/doc/environment.rst @@ -17,10 +17,13 @@ components which are available to the public). In order to build |ptxdistBSPName|, the following source archives have to be available on the development host: - * ptxdist-|ptxdistVendorVersion|.tar.bz2 + * `ptxdist-|ptxdistVendorVersion|.tar.bz2 <https://public.pengutronix.de/software/ptxdist/ptxdist-|ptxdistVendorVersion|.tar.bz2>`_ * |ptxdistBSPName|.tar.bz2 (or a similar source) - * ptxdist-|oselasTCNVendorptxdistversion|.tar.bz2 - * OSELAS.Toolchain-|oselasTCNVendorVersion|.tar.bz2 + +Additionally, those source archives are needed to build toolchain: + + * `OSELAS.Toolchain-|oselasTCNVendorVersion|.tar.bz2 <https://public.pengutronix.de/oselas/toolchain/OSELAS.Toolchain-|oselasTCNVendorVersion|.tar.bz2>`_ + * `ptxdist-|oselasTCNVendorptxdistversion|.tar.bz2 <https://public.pengutronix.de/software/ptxdist/ptxdist-|oselasTCNVendorptxdistversion|.tar.bz2>`_ Main Parts of PTXdist ~~~~~~~~~~~~~~~~~~~~~ > What's also lacking: some template or documentation on how to start from > scratch without deriving your work from pre existing BSPs. I tried that > lately and put the steps online: > > https://gist.github.com/LeSpocky/31af75ab63bc6f35fd71d53f06b5a50e > > I dropped that link in IRC, but I got no clear signal if that's something to > put into the official ptxdist documentation? I'm hereby sending a clear signal to maintainers that I'd like to see something like that in the documentation ;-) > > The documentation says having a BSP is optional, but there's no > > instructions on how to work without one. It's probably not even a good > > idea to mention this, perhaps ptxdist should provide a skeleton project? > > > > I get the distinct impression the right solution here is to use > > DistroKit as the starter BSP. This isn't mentioned anywhere in the > > documentation but is something I found out about on IRC. > > > > I'm also not a fan of suggesting installing ptxdist. It seems strange to > > lock yourself to a repository of packages that you will need to tweak > > and fix. I would like to see more support for running it in tree. > > Maybe this is some kind of misunderstanding. You would never touch the > distributed/installed ptxdist, but "overwrite" things by placing package > rules > with the same name in your BSP. For example if you need a version bump for > libfoo, you could copy /usr/local/lib/ptxdist-2100.01.0/rules/libfoo.make to > your BSP at rules/libfoo.make and adapt it to your needs. or you can even put that into post/ rules in case just upgrading package is sufficient (no configure, etc. changes)
