sqlite build failure on BSP bsets

[Joel Sherrill]

For those who might reference this in the future, this is the RSB command
I used to build sqlite last night from the RTEMS directory:

../source-builder/sb-set-builder \
  --log=l-sqlite.txt \
  --host=arm-rtems5 \
  --prefix=${HOME}/rtems-work/tools/5/bsp-install/ \
  --with-tools=${HOME}/rtems-work/tools/5 \
  --with-rtems-bsp=xilinx_zynq_a9_qemu \
  databases/sqlite

I had previously installed arm tools and the  xilinx_zynq_a9_qemu BSP.
Note that when working on RTEMS, I keep the tools and BSP installs
in separate directories. It makes it easier to remove BSPs.

Thanks again.

--joel

On Thu, Apr 2, 2020 at 7:23 PM Joel Sherrill <joel at rtems.org> wrote:

> Thank you so much Jonathon!  I have pushed this.
>
> We are really trying to close all issues and get things ready for a
> release. All help and user testing is appreciated.
>
> --joel
>
> On Thu, Apr 2, 2020 at 5:47 PM Jonathan Brandmeyer <
> jbrandmeyer at planetiq.com> wrote:
>
>> Try this.
>>
>> I changed the logic which avoids building the sqlite3 shell.  Something
>> about the way it uses libtool made the old `touch`-based method fail.
>> There's also a bunch of configuration notes that really ought to be more
>> visible.
>>
>> On Thu, Apr 2, 2020 at 2:26 PM Joel Sherrill <joel at rtems.org> wrote:
>>
>>>
>>>
>>> On Thu, Apr 2, 2020 at 3:00 PM Gedare Bloom <gedare at rtems.org> wrote:
>>>
>>>> On Thu, Apr 2, 2020 at 1:57 PM Jonathan Brandmeyer
>>>> <jbrandmeyer at planetiq.com> wrote:
>>>> >
>>>> >
>>>> > On Thu, Apr 2, 2020 at 1:43 PM Joel Sherrill <joel at rtems.org> wrote:
>>>> >>
>>>> >> Thank you for the detailed feedback.
>>>> >>
>>>> >> I am torn between:
>>>> >>
>>>> >> + deleting sqlite from the BSP bset's
>>>> >> + requiring tclsh to be installed
>>>> >> + updating the RSB recipe for sqlite.
>>>> >>
>>>> >> Given the desire to get a release out the door. I am prone to the
>>>> first
>>>> >> option with a ticket for 5.2 to update sqlite and re-add it to the
>>>> BSP
>>>> >> bsets.
>>>> >
>>>> >
>>>> > I can see where you're coming from.  That said, even having an
>>>> obsolete bset in the RSB served as a helpful hint that it worked for
>>>> someone once upon a time.
>>>> >
>>>> >>
>>>> >>
>>>> >> Since you obviously use sqlite, if you could tackle updating the RSB
>>>> >> recipe, that would be great and avoid having to do something
>>>> expedient
>>>> >> to get the release out the door.
>>>> >
>>>> >
>>>> >  I can make a pass at it.  What's the quickest way to iterate on a
>>>> BSET's rules?  I'd rather not have to wait on GCC and crew to rebuild when
>>>> I get it wrong the first time.
>>>> >
>>>> Use --dry-run option
>>>>
>>>
>>> This is good to watch the commands quickly.  But you can just explicitly
>>> build the one package.
>>>
>>> $ cd rtems
>>> $ ../source-builder/sb-set-builder \
>>>      --log=l-sqlite.txt \
>>>      --prefix=XXXX \
>>>       databases/sqlite
>>>
>>> Should be very close to working. I hacked my command for dtc so there
>>> may be a typo.
>>>
>>> This should take seconds.
>>>
>>> It is interesting that you didn't know you can build a single package
>>> or --dry-run. No foul to you. Just points out that we aren't letting the
>>> community know the cool things the RSB can do.
>>>
>>> I use the source download only option to get people to download things
>>> for the tools before they come to the Kick Start class. If they have
>>> network
>>> issues, can't fetch git, no admin, etc. then they can deal with those
>>> with
>>> their IT. I can't help with someone's draconian policies. :)
>>>
>>>
>>>>
>>>> >>
>>>> >> Chris will eventually wake up in Sydney and chime in. :)
>>>> >>
>>>> >
>>>> >
>>>> > --
>>>> > Jonathan Brandmeyer
>>>> > _______________________________________________
>>>> > devel mailing list
>>>> > devel at rtems.org
>>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>
>>
>> --
>> Jonathan Brandmeyer
>> Vice President of Software Engineering
>> PlanetiQ
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200403/59cbb962/attachment.html>