On Mon, May 29, 2023 at 2:41 AM Michael Gielda wrote:
>
> Haha, no worries, just subscribed on Friday for this particular reason :)
> glad Renode was useful for EOS S3 and of course happy to see how we can
> enable more of that.
>
>
> You mention you have a CI generating all the elfs, could you
On Wed, May 31, 2023 at 5:26 AM Brennan Ashton wrote:
> Still dropped him. Apparently I cannot use email correctly today...
Beware of big changes in quota handling at Google in recent days..
especially these using Workspace (Suite or whatever name it has now)..
I just got my email back to work aft
Haha, no worries, just subscribed on Friday for this particular reason :)
glad Renode was useful for EOS S3 and of course happy to see how we can
enable more of that.
You mention you have a CI generating all the elfs, could you point me to
where that can be found? We could grab those and try to r
Still dropped him. Apparently I cannot use email correctly today...
On Fri, May 26, 2023, 3:40 PM Brennan Ashton
wrote:
> Adding Michael back since I responded to him and he might not be on the
> list...
>
> On Fri, May 26, 2023 at 3:23 PM Brennan Ashton
> wrote:
> >
> >
> >
> > On Fri, May 26,
Adding Michael back since I responded to him and he might not be on the list...
On Fri, May 26, 2023 at 3:23 PM Brennan Ashton
wrote:
>
>
>
> On Fri, May 26, 2023, 3:11 PM Michael Gielda wrote:
>>
>> Hi Alan, nice to meet you Nathan,
>>
>> Indeed, we discussed with Alan some time ago, having a N
On Fri, May 26, 2023 at 3:11 PM Michael Gielda wrote:
>
> Hi Alan, nice to meet you Nathan,
>
> Indeed, we discussed with Alan some time ago, having a Nuttx-focused
> dashboard can be done and we assume would be useful. We just didn’t get to
> that as it would have been yet another research projec
On Fri, May 26, 2023, 3:11 PM Michael Gielda wrote:
> Hi Alan, nice to meet you Nathan,
>
> Indeed, we discussed with Alan some time ago, having a Nuttx-focused
> dashboard can be done and we assume would be useful. We just didn’t get to
> that as it would have been yet another research project (
Hi Alan, nice to meet you Nathan,
Indeed, we discussed with Alan some time ago, having a Nuttx-focused
dashboard can be done and we assume would be useful. We just didn’t get to
that as it would have been yet another research project (we are now also
building a U-Boot dashboard, as we added 64-bit
since
they are in the end the user.
Best regards
Alin
-Original Message-
From: Gregory Nutt
Sent: den 23 maj 2023 16:29
To: dev@nuttx.apache.org
Subject: Re: [OT] Learning Makefiles
On 5/23/2023 7:32 AM, Nathan Hartman wrote:
> On Tue, May 23, 2023 at 8:07 AM Tomek CEDRO wrote:
>&g
Here is the script to run the basic test:
https://github.com/apache/nuttx/blob/master/tools/ci/cirun.sh
Add a link in your config:
https://github.com/apache/nuttx/blob/master/boards/risc-v/qemu-rv/rv-virt/configs/citest/run
Build script will run it and report the result after the build pass:
https:
On Tue, May 23, 2023 at 10:06 AM Brennan Ashton
wrote:
>
> On Tue, May 23, 2023, 5:05 AM Nathan Hartman
> wrote:
>
> > On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
> > wrote:
> > > I have also asked in the past about cutting down on the amount of configs
> > > we have checked in to be somethin
On 5/23/23, Brennan Ashton wrote:
> On Tue, May 23, 2023, 5:05 AM Nathan Hartman
> wrote:
>
>> On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
>> wrote:
>> > I have also asked in the past about cutting down on the amount of
>> > configs
>> > we have checked in to be something like
>> >
>> > board
On 5/23/2023 7:32 AM, Nathan Hartman wrote:
On Tue, May 23, 2023 at 8:07 AM Tomek CEDRO wrote:
On Tue, May 23, 2023 at 9:31 AM Sebastien Lorquet wrote:
Hello Tomek,
Whatever is decided, the mere fact of wanting to make a decision on this
point will lead to more split.
either from people that w
On Tue, May 23, 2023, 5:05 AM Nathan Hartman
wrote:
> On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
> wrote:
> > I have also asked in the past about cutting down on the amount of configs
> > we have checked in to be something like
> >
> > board:nsh -- only nsh and somewhat small
> > board:jumbo
On Tue, May 23, 2023 at 8:07 AM Tomek CEDRO wrote:
>
> On Tue, May 23, 2023 at 9:31 AM Sebastien Lorquet wrote:
> > Hello Tomek,
> > Whatever is decided, the mere fact of wanting to make a decision on this
> > point will lead to more split.
> > either from people that want cmake
> > or from people
On Tue, May 23, 2023 at 7:48 AM Xiang Xiao wrote:
> Why not start the test infrastructure from sim/qemu? It's more simple to
> set up and has unlimited resources. Once the sim/qemu test workflow is
> ready, it isn't very hard to duplicate to the real boards.
Yeah, *:nsh should work that way, and s
On Tue, May 23, 2023 at 9:31 AM Sebastien Lorquet wrote:
> Hello Tomek,
> Whatever is decided, the mere fact of wanting to make a decision on this
> point will lead to more split.
> either from people that want cmake
> or from people who dont.
> this is an intrinsically bad decision
> Sebastien
I
On Tue, May 23, 2023 at 6:12 AM Brennan Ashton
wrote:
> I have also asked in the past about cutting down on the amount of configs
> we have checked in to be something like
>
> board:nsh -- only nsh and somewhat small
> board:jumbo -- nsh, plus as many features as can fit and are interesting in
> t
I agree with Brennan. If the ci build is too slow, let's optimize the ci
process instead of bypassing it totally. Since I have checked almost all ci
braak before, I expect that many board's config can't pass the compile
without the guard from the ci system. Actually, I think the big
imperfection of
On Mon, May 22, 2023, 12:14 PM Nathan Hartman
wrote:
> On Mon, May 22, 2023 at 9:29 AM Sebastien Lorquet
> wrote:
>
> >
> > If the untold reason is to speed up github tests, then run less tests.
> > Do we really need to test build on 13 or 20 arm platforms when only one
> > config of the other a
Hi,
I think it could work too, if pull requests are not delayed by more than
8 hours each... Not counting the complete restarts as soon as we push
fixes to existing PR...
Sebastien
Le 23/05/2023 à 11:02, Lee, Lup Yuen a écrit :
Maybe we can run the CI Tests once a day, so it's easier to bac
Maybe we can run the CI Tests once a day, so it's easier to backtrack? FYI
I've run Automated Tests on BL602 NuttX over the past 365 days (except for
the brief Makefile outage last week):
https://github.com/lupyuen/nuttx/tags
Here's how it works:
https://lupyuen.github.io/articles/auto
Lup
On
Hello,
even if theoretically nice to do, do we really, actually, need to do
that for the purpose of checking *every* pull request, which are quite
numerous?
Could that not be done once before a release?
Sebastien
Le 22/05/2023 à 22:31, Maciej Wójcik a écrit :
Checking different configurati
Hello Tomek,
Whatever is decided, the mere fact of wanting to make a decision on this
point will lead to more split.
either from people that want cmake
or from people who dont.
this is an intrinsically bad decision
Sebastien
Le 23/05/2023 à 01:41, Tomek CEDRO a écrit :
I can see that thi
Why not start the test infrastructure from sim/qemu? It's more simple to
set up and has unlimited resources. Once the sim/qemu test workflow is
ready, it isn't very hard to duplicate to the real boards.
On Tue, May 23, 2023 at 8:42 AM Alan C. Assis wrote:
> On 5/22/23, Tomek CEDRO wrote:
> > Th
On Tue, May 23, 2023 at 4:28 AM Xiang Xiao wrote:
> CWIKI mayn't be a good place since it requires that the user has an Apache
> account at least to make any change as far as I know.
> It's better to be tracked by a github issue.
That is more to keep RFC and administrative stuff documented.. anyon
CWIKI mayn't be a good place since it requires that the user has an Apache
account at least to make any change as far as I know.
It's better to be tracked by a github issue.
On Tue, May 23, 2023 at 9:27 AM Nathan Hartman
wrote:
> On Mon, May 22, 2023 at 8:44 PM Alan C. Assis wrote:
>
> > On 5/2
On Mon, May 22, 2023 at 8:44 PM Alan C. Assis wrote:
> On 5/22/23, Tomek CEDRO wrote:
> > On Tue, May 23, 2023 at 1:55 AM Alan C. Assis wrote:
> >> I think it is better to keep the documentation in a single place:
> >> https://nuttx.apache.org/docs/latest/contributing/index.html
> >> We're movin
On 5/22/23, Tomek CEDRO wrote:
> On Tue, May 23, 2023 at 1:55 AM Alan C. Assis wrote:
>> I think it is better to keep the documentation in a single place:
>> https://nuttx.apache.org/docs/latest/contributing/index.html
>> We're moving those documentations from confluence to our internal
>> reposit
On 5/22/23, Tomek CEDRO wrote:
> This is why I asked not that long ago about
> Software-Hardware-Support-Compatibility-Matrix.. this would be really
> big table with hardware boards in columns and features in rows with
> green marks (or +1) where full support is confirmed, yellow (or 0)
> meaning
On Tue, May 23, 2023 at 1:55 AM Alan C. Assis wrote:
> I think it is better to keep the documentation in a single place:
> https://nuttx.apache.org/docs/latest/contributing/index.html
> We're moving those documentations from confluence to our internal repository.
> So, that could be nice if you cou
On 5/22/23, Tomek CEDRO wrote:
> On Sat, May 20, 2023 at 2:12 AM Brennan Ashton wrote:
>> On Fri, May 19, 2023, 3:23 PM Tomek CEDRO wrote:
>> > I am thinking about this. "If it works don't fix it" comes to my mind.
>> > Current build system is amazingly simple coherent and fast. Building
>> > firm
On Sat, May 20, 2023 at 2:12 AM Brennan Ashton wrote:
> On Fri, May 19, 2023, 3:23 PM Tomek CEDRO wrote:
> > I am thinking about this. "If it works don't fix it" comes to my mind.
> > Current build system is amazingly simple coherent and fast. Building
> > firmware takes 17 seconds. Why change it?
This is why I asked not that long ago about
Software-Hardware-Support-Compatibility-Matrix.. this would be really
big table with hardware boards in columns and features in rows with
green marks (or +1) where full support is confirmed, yellow (or 0)
meaning work-in-progress, red (or -1) meaning no s
Checking different configurations is an academic problem, I think they call
it configuration sampling and it is part of variability modelling. There
were some papers about sampling of Linux configurations.
The simplest approach is to enable all possible, disable all possible, but
it is not trivial
On Mon, May 22, 2023 at 9:29 AM Sebastien Lorquet
wrote:
>
> If the untold reason is to speed up github tests, then run less tests.
> Do we really need to test build on 13 or 20 arm platforms when only one
> config of the other architectures is tested, and the actual value of
> these build test i
Hello,
Build performance is not an argument. it's already very fast.
Integration with various tools is a case of "I dont like it", it's not a
good reason for such a fundamental change, it can be resolved with local
configurations.
I cant find any good reason to change except, maybe, complexi
Hi Sebastien,
There are good cons and pros arguments for moving to CMake.
Just like many here I don' t have preference for one or another, but
we need to analyze what is better for NuttX evolution and make a good
decision.
The main pros of moving to CMake:
1) It is easier to integrate with new
I very much agree with all of these arguments.
Thats a too large disruption for too little benefits.
I dont want to be forced to use cmake.
Everything we use here to integrate NuttX is based on makefiles.
Why do we have to bring in yet another dependency? No, cmake is not
installed in our bui
On Fri, May 19, 2023, 3:23 PM Tomek CEDRO wrote:
> I am thinking about this. "If it works don't fix it" comes to my mind.
>
> Current build system is amazingly simple coherent and fast. Building
> firmware takes 17 seconds. Why change it?
>
> Such change will flip everything upside down. Adds lot
I am thinking about this. "If it works don't fix it" comes to my mind.
Current build system is amazingly simple coherent and fast. Building
firmware takes 17 seconds. Why change it?
Such change will flip everything upside down. Adds lots of work and
even more possible problems.
What would be the
On Fri, May 19, 2023 at 12:53 PM Gregory Nutt wrote:
> On 5/19/2023 10:25 AM, Lwazi Dube wrote:
> > Alan,
> >
> > Can you summarize? I have not been following this PR. Is make going away?
> >
> > Thanks,
> >
> > -Lwazi
> >
> > On Fri, 19 May 2023 at 11:47, Alan C. Assis wrote:
> >> Hi Everyone,
On Fri, May 19, 2023 at 8:10 PM Gregory Nutt wrote:
> > Such a big change needs good description.. risks.. clear list of
> > advantages and disadvantages :-)
>
> And if it comes down to switching from one to the other as you suggest,
> then it needs a vote to understand the will of the whole commun
On 5/19/2023 12:11 PM, Lwazi Dube wrote:
On Fri, 19 May 2023 at 13:51, Alan C. Assis wrote:
Lwazi, I think Greg summarized it well.
Yes, and Maciej too. Thanks
But we need to get away from statements of fears and marketing
statements to understand the clear, real world impacts.
On Fri, 19 May 2023 at 13:51, Alan C. Assis wrote:
>
> Lwazi, I think Greg summarized it well.
>
Yes, and Maciej too. Thanks
Such a big change needs good description.. risks.. clear list of
advantages and disadvantages :-)
And if it comes down to switching from one to the other as you suggest,
then it needs a vote to understand the will of the whole community, not
the preference of a few. The whole community wou
On 5/19/23, Gregory Nutt wrote:
> On 5/19/2023 10:25 AM, Lwazi Dube wrote:
>> Alan,
>>
>> Can you summarize? I have not been following this PR. Is make going away?
>>
>> Thanks,
>>
>> -Lwazi
>>
>> On Fri, 19 May 2023 at 11:47, Alan C. Assis wrote:
>>> Hi Everyone,
>>>
>>> While PR #6718 is waitin
I see the following advantages of having CMake:
- Everything is way more readable then the current Make files.
- Easier on-boarding.
- Less build-related bugs.
- Less boiler-plate code.
- Faster builds.
- Great IDE integration.
Adding CMake as an optional feature seems to be a great solution.
Mai
On Fri, May 19, 2023 at 7:17 PM Xiang Xiao wrote:
> The change doesn't replace Makefile with CMake, both can work. So I would
> suggest the vote is "Enable CMake support".
Isn't the goal of CMake to generate Makefiles?
What is the chance of keeping both makefiles and cmakefiles out of sync?
Woul
The change doesn't replace Makefile with CMake, both can work. So I would
suggest the vote is "Enable CMake support".
On Sat, May 20, 2023 at 12:53 AM Gregory Nutt wrote:
> On 5/19/2023 10:25 AM, Lwazi Dube wrote:
> > Alan,
> >
> > Can you summarize? I have not been following this PR. Is make go
On 5/19/2023 10:25 AM, Lwazi Dube wrote:
Alan,
Can you summarize? I have not been following this PR. Is make going away?
Thanks,
-Lwazi
On Fri, 19 May 2023 at 11:47, Alan C. Assis wrote:
Hi Everyone,
While PR #6718 is waiting to get merged, please take a look:
https://makefiletutorial.com
Alan,
Can you summarize? I have not been following this PR. Is make going away?
Thanks,
-Lwazi
On Fri, 19 May 2023 at 11:47, Alan C. Assis wrote:
>
> Hi Everyone,
>
> While PR #6718 is waiting to get merged, please take a look:
>
> https://makefiletutorial.com
>
> BR,
>
> Alan
Hi Everyone,
While PR #6718 is waiting to get merged, please take a look:
https://makefiletutorial.com
BR,
Alan
53 matches
Mail list logo
