On Thu, Sep 16, 2021, 6:36 PM Chris Johns <chr...@rtems.org> wrote: > On 16/9/21 10:59 pm, Joel Sherrill wrote: > > On Wed, Sep 15, 2021 at 7:08 PM Chris Johns <chr...@rtems.org> wrote: > >> On 16/9/21 1:46 am, Joel Sherrill wrote: > >>> On Tue, Sep 14, 2021 at 5:52 PM Chris Johns <chr...@rtems.org> wrote: > >>>> On 15/9/21 4:49 am, Joel Sherrill wrote: > >>> The issue I mentioned is that the same rtems-tools-@t...@-1.tar.bz2 > >>> is used for every architecture. Perhaps rtems-tools-@ARCH@-@TAG@ > -1.tar.bz2. > >>> Then you can script building all architectures without renaming files. > >> > >> That implies the tools are arch specific and they are not. The tools > should be > >> tagged with the host arch details if we add anything. > > > > The issue is that the tarball name is wrong and the rtems-tools one > rtems-tools, > > binutils, gcc/newlib, and gdb. It includes EVERYTHING that is built > > when you use 6/rtems-arm. > > I am not surprised, maybe the staging changes may have effected the tar > naming? > > If you wanted to select a parent which parent would be selected? >
I don't mind everything being lumped together. Except for rtems-tools, it is all an arm RTEMS tool chain which is why it never struck me that it was using the repo rtems-tools as the name. Maybe rtems-toolchain-CPU. Ideally rtems-tools would be separate. Maybe a variable to define the package name to override some default. > > The current design packages at the config file level it gives you the > various > pieces as a single block so you can packages them. A single tarball for > the top > level would make it hard for someone to use to make packages that can be > deployed. > > For tools the name of the tarball needs to match the contents and it is > native. > The fact each arch bset builds the same thing is a side effect of the > packaging > being used. Adding the arch might create the impression each arch tools > package > has to be kept separate. > > > The automake tarball has automake and autoconf > > I am not sure why this is happening. Maybe 2 tarballs should be created. > This > stuff is a little more complicated because of the internal build stage. > Autoconf > and automake cannot be cleanly relocated so in installers I have created > in the > past I had the installer build the packages using the install prefix. > This one isn't critical as we aren't using it going forward. This is an issue on 5 and older. > > The rtems-tools tarball has everything I listed above. Beyond > > rtems-tools, binutils, > > gcc/newlib, and gdb, I suppose it also includes sis or dtc on some > > architectures. > > Do you want the RSB to generate user accessible tar files that need no > further > touching? > Ideally they shouldn't be named the same. I don't particularly care if they duplicate files. Packages would be nice not to duplicate since we should be able to control that. I'm already post processing to extract a common tarball. But the names and contents of the RSB generated tarballs don't accurately reflect the contents and don't reflect the target CPU (or host). > > > If it used the name from the top level bset it might be ok. Then you > would have > > autotools and something derived from 6/rtems-arm > > Yeap. > > > I can send you lists of what is in each tarball if you like. > > No need, I have an OK idea of what is contained in the packages > Ok > > > Chris > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
