On 13/03/15 14:21, Amar Takhar wrote:
>Information hiding is a key principle in software engineering.
But not software testing. If you hide information it makes software difficult
to test as the testable areas become less obvious. If you hide interfaces
behind layers of includes what ends up
On 2015-03-13 13:57 +0100, Sebastian Huber wrote:
>
>
> On 13/03/15 13:38, Amar Takhar wrote:
> > On 2015-03-13 09:45 +0100, Sebastian Huber wrote:
> >>> #include
> >>> -Iinclude/cpu/sparc/sis/
> >> This is exactly what we need.
> > I agree we need this right now but it's not a requirement for t
On 13/03/15 13:38, Amar Takhar wrote:
On 2015-03-13 09:45 +0100, Sebastian Huber wrote:
#include
-Iinclude/cpu/sparc/sis/
This is exactly what we need.
I agree we need this right now but it's not a requirement for the future.
For me this is a requirement for the future. A lot of applicati
On 2015-03-13 09:45 +0100, Sebastian Huber wrote:
> > #include
> > -Iinclude/cpu/sparc/sis/
>
> This is exactly what we need.
I agree we need this right now but it's not a requirement for the future.
> > The whole purpose of explicit paths it to avoid picking up the wrong header
> > file which
On 13/03/15 01:48, Amar Takhar wrote:
On 2015-03-13 11:36 +1100, Chris Johns wrote:
There is complexity in terms of what a user sees which we need to address.
I also have no problem with more than one -I when building RTEMS and
feel we have too. I cannot see a suitable way around this.
This
On 13/03/2015 11:48 am, Amar Takhar wrote:
On 2015-03-13 11:36 +1100, Chris Johns wrote:
There is complexity in terms of what a user sees which we need to address.
I also have no problem with more than one -I when building RTEMS and
feel we have too. I cannot see a suitable way around this.
Th
On 2015-03-13 11:36 +1100, Chris Johns wrote:
> There is complexity in terms of what a user sees which we need to address.
>
> I also have no problem with more than one -I when building RTEMS and
> feel we have too. I cannot see a suitable way around this.
>
> This means we might end up with:
>
On 13/03/2015 1:51 am, Sebastian Huber wrote:
- Amar Takhar schrieb:
On 2015-03-12 09:45 -0400, Gedare Bloom wrote:
This doesn't work in supposedly CPU-independent source code files.
Let's take percpu.h as an example. We need to include it in
-- the main header for thread scheduling tha
On 11/03/2015 12:42 pm, Amar Takhar wrote:
On 2015-03-11 00:36 +0100, Pavel Pisa wrote:
Hello Amar,
thanks for reply.
On Tuesday 10 of March 2015 19:00:03 Amar Takhar wrote:
On 2015-03-10 11:03 +0100, Pavel Pisa wrote:
I think that includes really belong near to the implementation and that
n
- Amar Takhar schrieb:
> On 2015-03-12 09:45 -0400, Gedare Bloom wrote:
> > This doesn't work in supposedly CPU-independent source code files.
> >
> > Let's take percpu.h as an example. We need to include it in
> > -- the main header for thread scheduling that
> > is included by virtually e
On Thu, Mar 12, 2015 at 10:08 AM, Joel Sherrill
wrote:
>
>
> On March 12, 2015 8:56:36 AM CDT, Gedare Bloom wrote:
>>On Thu, Mar 12, 2015 at 9:51 AM, Amar Takhar wrote:
>>> On 2015-03-12 09:45 -0400, Gedare Bloom wrote:
This doesn't work in supposedly CPU-independent source code files.
On March 12, 2015 8:56:36 AM CDT, Gedare Bloom wrote:
>On Thu, Mar 12, 2015 at 9:51 AM, Amar Takhar wrote:
>> On 2015-03-12 09:45 -0400, Gedare Bloom wrote:
>>> This doesn't work in supposedly CPU-independent source code files.
>>>
>>> Let's take percpu.h as an example. We need to include it in
On Thu, Mar 12, 2015 at 9:51 AM, Amar Takhar wrote:
> On 2015-03-12 09:45 -0400, Gedare Bloom wrote:
>> This doesn't work in supposedly CPU-independent source code files.
>>
>> Let's take percpu.h as an example. We need to include it in
>> -- the main header for thread scheduling that
>> is inclu
On 2015-03-12 09:45 -0400, Gedare Bloom wrote:
> This doesn't work in supposedly CPU-independent source code files.
>
> Let's take percpu.h as an example. We need to include it in
> -- the main header for thread scheduling that
> is included by virtually every source file in the supercore. We can
On Thu, Mar 12, 2015 at 9:21 AM, Amar Takhar wrote:
> On 2015-03-12 14:19 +0100, Sebastian Huber wrote:
>>
>>
>> On 12/03/15 14:13, Amar Takhar wrote:
>> > On 2015-03-12 14:10 +0100, Sebastian Huber wrote:
>> >>
>> >>> #include
>> >>> #include
>> >> This will not work. We have sparc, arm, powerp
On 2015-03-12 14:19 +0100, Sebastian Huber wrote:
>
>
> On 12/03/15 14:13, Amar Takhar wrote:
> > On 2015-03-12 14:10 +0100, Sebastian Huber wrote:
> >>
> >>> #include
> >>> #include
> >> This will not work. We have sparc, arm, powerpc etc. and they must not
> >> be visible at the same time.
>
On 12/03/15 14:13, Amar Takhar wrote:
On 2015-03-12 14:10 +0100, Sebastian Huber wrote:
#include
#include
This will not work. We have sparc, arm, powerpc etc. and they must not
be visible at the same time.
What do you mean by 'visible'?
If I build for arm, then I need the arm and not
On 2015-03-12 14:10 +0100, Sebastian Huber wrote:
>
>
> > #include
> > #include
>
> This will not work. We have sparc, arm, powerpc etc. and they must not
> be visible at the same time.
What do you mean by 'visible'?
> > The names of some headers would have to be changed to avoid confusion
On 12/03/15 14:05, Amar Takhar wrote:
On 2015-03-12 13:57 +0100, Sebastian Huber wrote:
On 11/03/15 13:04, Amar Takhar wrote:
On 2015-03-11 09:44 +0100, Sebastian Huber wrote:
We need at least three -I options, one for the BSP headers, one for the
CPU headers and one for the rest.
The curr
On 2015-03-12 08:01 -0500, Joel Sherrill wrote:
> What will happen to source modules that are third party? Will we blend their
> .h with our own? Will this negatively impact the integrity of a source import?
Yes, their public APIs will become part of our own. If we take ownership we
will be ab
On 2015-03-12 13:57 +0100, Sebastian Huber wrote:
>
>
> On 11/03/15 13:04, Amar Takhar wrote:
> > On 2015-03-11 09:44 +0100, Sebastian Huber wrote:
> >> >We need at least three -I options, one for the BSP headers, one for the
> >> >CPU headers and one for the rest.
> > The current one uses only o
On March 11, 2015 3:44:04 AM CDT, Sebastian Huber
wrote:
>
>
>On 09/03/15 18:02, Amar Takhar wrote:
>> On 2015-03-09 14:18 +0100, Sebastian Huber wrote:
>>> >This is actually a big problem and will break a lot of thinks.
>Currently
>>> >you use
>>> >
>>> >#include
>>> >
>>> >and get for exampl
On 11/03/15 13:04, Amar Takhar wrote:
On 2015-03-11 09:44 +0100, Sebastian Huber wrote:
>We need at least three -I options, one for the BSP headers, one for the
>CPU headers and one for the rest.
The current one uses only one -I because all paths will be explicit. Right now
I've hacked aroun
On 2015-03-10 11:03 +0100, Pavel Pisa wrote:
> Hello Amar and others,
>
> I would like to express my weak objection to moving
> all includes to single directory. This makes sources
> much less modular is (according to me) backward move.
All input is welcome!
> I think that includes really belon
On 2015-03-11 09:44 +0100, Sebastian Huber wrote:
> We need at least three -I options, one for the BSP headers, one for the
> CPU headers and one for the rest.
The current one uses only one -I because all paths will be explicit. Right now
I've hacked around the problem with the header redirecto
On 09/03/15 18:02, Amar Takhar wrote:
On 2015-03-09 14:18 +0100, Sebastian Huber wrote:
>This is actually a big problem and will break a lot of thinks. Currently
>you use
>
>#include
>
>and get for example RTEMS_BSP_NETWORK_DRIVER_ATTACH for the network
>configuration.
>
>You find the via th
On 2015-03-11 00:36 +0100, Pavel Pisa wrote:
> Hello Amar,
>
> thanks for reply.
>
> On Tuesday 10 of March 2015 19:00:03 Amar Takhar wrote:
> > On 2015-03-10 11:03 +0100, Pavel Pisa wrote:
> > > I think that includes really belong near to the implementation and that
> > > new architecture could
Hello Amar,
thanks for reply.
On Tuesday 10 of March 2015 19:00:03 Amar Takhar wrote:
> On 2015-03-10 11:03 +0100, Pavel Pisa wrote:
> > I think that includes really belong near to the implementation and that
> > new architecture could be (in optimal case) introduced by adding single
> > director
Hello Amar and others,
I would like to express my weak objection to moving
all includes to single directory. This makes sources
much less modular is (according to me) backward move.
Linux kernel used that setup
/include
/include/linux
/include/x86/asm
...
and it took developers may it be ye
On 2015-03-09 14:18 +0100, Sebastian Huber wrote:
> This is actually a big problem and will break a lot of thinks. Currently
> you use
>
> #include
>
> and get for example RTEMS_BSP_NETWORK_DRIVER_ATTACH for the network
> configuration.
>
> You find the via the -B compiler switch.
This will
On 09/03/15 02:42, Amar Takhar wrote:
> >include/arch/- Private architecture specific
> >include/bsp/ - Common BSP files
> >include/bsp/ - Architecture specific
>
>Does this mean all references are explicit and not using compiler
>include path tricks ?
Yes, 100% of include p
On 2015-03-09 08:39 +1100, Chris Johns wrote:
> On 8/03/2015 12:51 pm, Amar Takhar wrote:
> Thanks for starting this thread. Reorganising the source tree in RTEMS
> is long over due.
You're welcome! The source layout was the second biggest issue I had with
navigating the code.
>
> I assume t
On 8/03/2015 12:51 pm, Amar Takhar wrote:
Please ignore the previous include layout the correct is below copied from
another email in this thread:
Thanks for starting this thread. Reorganising the source tree in RTEMS
is long over due.
I assume this is all post 4.11 and based on the up comin
On 2015-03-07 09:44 +0100, Dominik Taborsky wrote:
> Just one question here: Why have the public API hidden in a subdir of
> private APIs? Shouldn't this be the other way around?
I just noticed the layout I gave above was wrong! Gedare sent me an
email (he could not email the list directly from
Please ignore the previous include layout the correct is below copied from
another email in this thread:
I just noticed the layout I gave above was wrong! Gedare sent me an
email (he could not email the list directly from his device). I had a typo in
the original one and also didn't copy t
On 2015-03-07 09:44 +0100, Dominik Taborsky wrote:
> I am a newbie to RTEMS, but this sounds great. The current layout is
> very confusing to newcomers. Kudos to you, Amar!
> Please, see my notes further on.
Great to hear input from new users, thank you!
> > include locations
> > ~~
I am a newbie to RTEMS, but this sounds great. The current layout is
very confusing to newcomers. Kudos to you, Amar!
Please, see my notes further on.
On 03/07/2015 02:20 AM, Amar Takhar wrote:
The following is a proposal for a new source layout that will be included in the
new 'waf&#
The following is a proposal for a new source layout that will be included in
the
new 'waf' build system. The current layout is a product of years of laying and
requirements for the auto* build system. Since we are no longer restricted by
this it makes sense to take the time and gi
38 matches
Mail list logo
