Re: Compressed patch to move make/custom/* to make/*

2018-02-11 Thread Chris Johns 
On 9/2/18 7:07 pm, Sebastian Huber wrote:
> On 09/02/18 00:47, Chris Johns wrote:
>>>  No user should be forced to touch its Makefiles only because we move 
>>> some
>>>  files in the RTEMS source tree from A to B. So, I think the install
>>> location
>>>  should remain as is.
>>>
>>>
>>> I agree but I think you missed my point. The use in testsuites can be fixed
>>> to point
>>> to the source tree.  But if I change the includes in the "custom" files, I 
>>> have
>>> concerns
>>> that it may not be possible to make it work in both when building and 
>>> installed.
>>>
>> Exporting anything internal to users is always going to present a risk, we 
>> have
>> known and acknowledged this for years. It has been part of the reason we have
>> avoided making changes in the build system however my attitude is changing or
>> has changed, ie removing preinstall.
>>
>> Long term I cannot see how we can sustain this interface and that means we 
>> need
>> to determine when it goes? I am more than happy to be proved wrong. It is 
>> only
>> fair to those who use these installed files they get suitable warning and we
>> need to figure out what we provide to replace it.
>>
>> Building new applications and products based on this type of application 
>> build
>> framework with RTEMS 5 should be discouraged. We are looking to increase the
>> release frequency and this will only shorten the life span for these files.
>>
> 
> I think it will not cost much to simply leave this stuff as is.

From a file exporting point of view sure, however do we need to ensure anything
internal is consistent with the export requirements that exist? If we get a
conflict which side has to handle it?

The ability for BSP developers to add any valid make syntax means we do not know
what is actually being used by users of a BSP. The post link format support is
an example and another is the special link addresses, for example the rtems_waf
support for building with waf from the .pc files has to hold tweaks [1] because
there is no standard means to handle exporting this info from the make syntax to
anything else so it is not present. As a result I am pretty sure we will break
things.

[1] https://git.rtems.org/chrisj/rtems_waf.git/tree/rtems.py#n325

> It should be
> easy to support with any RTEMS internal build system. The only thing we really
> need are the machine flags for the BSP.

What about post-link formatting? If we limit RTEMS to building just to the ELF
then that is true.

> We need a better place to specify them.

Do we move all the detail to pkgconfig format files we can just export as a copy
and then have RTEMS's build system use those to extract the pieces it needs?

I am OK with pkgconfig because there are a few implementations about that are
not based on the recursive build process of the main package. One is in the RSB
and rtems_waf packages written in Python.

> The blocking points for the next step of build system clean up are from my 
> point
> of view (highest priority first):
> 
> 1. The host tools, they should move to rtems-tools or even go away if no 
> longer
> used. Getting rid of the native compiler for BSP builds will simplify things.

Good idea.

> 2. The libcpu, the files should move to bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/* 
> or
> bsps/@RTEMS_CPU@/shared/*.

Top level 'bsp' or 'arch', an 'arch' directory is a sort of a defacto standard?
Could you have arch/@RTEMS_CPU@/score, arch/@RTEMS_CPU@/contrib,
arch/@RTEMS_CPU@/dev, arch/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/* etc?

I just wonder if adding CPU support like this under bsps is making extra rules
like bsp/@RTEMS_BSP_FAMILY@/* == arch?

> 3. Move the machine flags out of the *.cfg files. Make them usable by 
> arbitrary
> build systems.

As suggested above we could move them to .pc files and then have the build
system use them?

I think we need to consider more than the just the machine flags.

> 4. Make the BSP options independent of Autoconf, so that it can be used from
> Autoconf and other build systems.

Same.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

2018-02-09 Thread Sebastian Huber 

On 09/02/18 00:47, Chris Johns wrote:

 No user should be forced to touch its Makefiles only because we move some
 files in the RTEMS source tree from A to B. So, I think the install 
location
 should remain as is.


I agree but I think you missed my point. The use in testsuites can be fixed to 
point
to the source tree.  But if I change the includes in the "custom" files, I have
concerns
that it may not be possible to make it work in both when building and installed.


Exporting anything internal to users is always going to present a risk, we have
known and acknowledged this for years. It has been part of the reason we have
avoided making changes in the build system however my attitude is changing or
has changed, ie removing preinstall.

Long term I cannot see how we can sustain this interface and that means we need
to determine when it goes? I am more than happy to be proved wrong. It is only
fair to those who use these installed files they get suitable warning and we
need to figure out what we provide to replace it.

Building new applications and products based on this type of application build
framework with RTEMS 5 should be discouraged. We are looking to increase the
release frequency and this will only shorten the life span for these files.



I think it will not cost much to simply leave this stuff as is. It 
should be easy to support with any RTEMS internal build system. The only 
thing we really need are the machine flags for the BSP. We need a better 
place to specify them. The blocking points for the next step of build 
system clean up are from my point of view (highest priority first):


1. The host tools, they should move to rtems-tools or even go away if no 
longer used. Getting rid of the native compiler for BSP builds will 
simplify things.


2. The libcpu, the files should move to 
bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/* or bsps/@RTEMS_CPU@/shared/*.


3. Move the machine flags out of the *.cfg files. Make them usable by 
arbitrary build systems.


4. Make the BSP options independent of Autoconf, so that it can be used 
from Autoconf and other build systems.


What is the benefit of moving files from

c/src/lib/libbsp/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/make/custom

to

c/src/lib/libbsp/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/make

?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

2018-02-08 Thread Chris Johns 
On 09/02/2018 02:22, Joel Sherrill wrote:
> On Thu, Feb 8, 2018 at 9:10 AM, Sebastian Huber
>  >
> wrote:
> On 08/02/18 16:08, Joel Sherrill wrote:
> On Thu, Feb 8, 2018 at 3:05 AM, Sebastian Huber
>  
>  >> wrote:
> 
> On 08/02/18 09:11, Sebastian Huber wrote:
> 
> On 08/02/18 01:00, Joel Sherrill wrote:
> 
> Hi
> 
> The patch was quite large and rightly blocked from being
> sent to
> everyone (~900k). Compressed, it is only 63K
> 
> This eliminates the custom directory and moves everything 
> up
> one level.  No failures in the build as shown here.
> 
>
> https://lists.rtems.org/pipermail/build/2018-February/000398.html
> 
>
>  >
> 
> 
> If we move this stuff, then why not to
> 
> bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make
> 
> 
> OK. I can pick at that but what does from testsuites this change to?
> 
> include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
> 
> Will RTEMS_ROOT need to change to something like $(top_srcdir)/...?
> 
> Is there a Makefile.am variable that really points to the top of the
> source tree?
> 
> The other common pattern is
> 
> include $(RTEMS_ROOT)/make/custom/default.cfg
> 
> in all the BSP .cfg files? What will that need to be to work before 
> and
> after install?
> 
> RTEMS_ROOT is the build tree and later the install point. I don't
> know how to make that one work.
> 
> Any thoughts?
> 
> 
> No user should be forced to touch its Makefiles only because we move some
> files in the RTEMS source tree from A to B. So, I think the install 
> location
> should remain as is.
> 
> 
> I agree but I think you missed my point. The use in testsuites can be fixed 
> to point
> to the source tree.  But if I change the includes in the "custom" files, I 
> have
> concerns
> that it may not be possible to make it work in both when building and 
> installed. 
> 

Exporting anything internal to users is always going to present a risk, we have
known and acknowledged this for years. It has been part of the reason we have
avoided making changes in the build system however my attitude is changing or
has changed, ie removing preinstall.

Long term I cannot see how we can sustain this interface and that means we need
to determine when it goes? I am more than happy to be proved wrong. It is only
fair to those who use these installed files they get suitable warning and we
need to figure out what we provide to replace it.

Building new applications and products based on this type of application build
framework with RTEMS 5 should be discouraged. We are looking to increase the
release frequency and this will only shorten the life span for these files.

> ./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv_devkit.cfg:include
> $(RTEMS_ROOT)/make/custom/altcycv.inc
> ./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv_devkit_smp.cfg:include
> $(RTEMS_ROOT)/make/custom/altcycv.inc
> ./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv.inc:include
> $(RTEMS_ROOT)/make/custom/default.cfg
> 
> I just grep'ed for RTEMS_ROOT and it appears that I need to change the 
> definition
> of where it points. It is mostly used to point to the custom files but this 
> looks 
> problematic:
> 
> /c/src/Makefile.am:'RTEMS_BSP=@RTEMS_BSP@' 'RTEMS_ROOT=.' \
> ./c/src/configure.ac:RTEMS_ROOT=. make/${RTEMS_BSP}.cache
> 
> All the references in testsuites can be to top_srcdir. Easy to eliminate 
> RTEMS_ROOT
> completely I think in there. But what should RTEMS_ROOT be set to in
> c/src/configure.ac  to make it work? What variable has 
> the
> top of the source tree?
> 
> I guess $(top_srcdir)/../..?
> > Thoughts?
> 

You are entering a swamp made of "top.*" labelled quick sand as I found out in
the preinstall removal. Top is relative and is implemented as a hack I refrain
from fully explaining so I do not offend. There are a number of "tops" in the
tree and then there are lists of ".."s to go up and down and that number depends
on the relative point to the "top" you are under. There are no consistent rules
across the source and it depends on a mix of different .m4 pieces with the same
macro and files names in different aclocal directories that are effected by the
command line options to the nested configure calls that is c

Re: Compressed patch to move make/custom/* to make/*

2018-02-08 Thread Joel Sherrill 
On Thu, Feb 8, 2018 at 9:10 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/02/18 16:08, Joel Sherrill wrote:
>
>>
>> On Thu, Feb 8, 2018 at 3:05 AM, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de > ed-brains.de>> wrote:
>>
>> On 08/02/18 09:11, Sebastian Huber wrote:
>>
>> On 08/02/18 01:00, Joel Sherrill wrote:
>>
>> Hi
>>
>> The patch was quite large and rightly blocked from being
>> sent to
>> everyone (~900k). Compressed, it is only 63K
>>
>> This eliminates the custom directory and moves everything up
>> one level.  No failures in the build as shown here.
>>
>> https://lists.rtems.org/pipermail/build/2018-February/000398
>> .html
>> > 8.html>
>>
>>
>> If we move this stuff, then why not to
>>
>> bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make
>>
>>
>> OK. I can pick at that but what does from testsuites this change to?
>>
>> include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
>>
>> Will RTEMS_ROOT need to change to something like $(top_srcdir)/...?
>>
>> Is there a Makefile.am variable that really points to the top of the
>> source tree?
>>
>> The other common pattern is
>>
>> include $(RTEMS_ROOT)/make/custom/default.cfg
>>
>> in all the BSP .cfg files? What will that need to be to work before and
>> after install?
>>
>> RTEMS_ROOT is the build tree and later the install point. I don't
>> know how to make that one work.
>>
>> Any thoughts?
>>
>
> No user should be forced to touch its Makefiles only because we move some
> files in the RTEMS source tree from A to B. So, I think the install
> location should remain as is.


I agree but I think you missed my point. The use in testsuites can be fixed
to point
to the source tree.  But if I change the includes in the "custom" files, I
have concerns
that it may not be possible to make it work in both when building and
installed.

./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv_devkit.cfg:include
$(RTEMS_ROOT)/make/custom/altcycv.inc
./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv_devkit_smp.cfg:include
$(RTEMS_ROOT)/make/custom/altcycv.inc
./c/src/lib/libbsp/arm/altera-cyclone-v/make/custom/altcycv.inc:include
$(RTEMS_ROOT)/make/custom/default.cfg

I just grep'ed for RTEMS_ROOT and it appears that I need to change the
definition
of where it points. It is mostly used to point to the custom files but this
looks
problematic:

/c/src/Makefile.am:'RTEMS_BSP=@RTEMS_BSP@' 'RTEMS_ROOT=.' \
./c/src/configure.ac:RTEMS_ROOT=. make/${RTEMS_BSP}.cache

All the references in testsuites can be to top_srcdir. Easy to eliminate
RTEMS_ROOT
completely I think in there. But what should RTEMS_ROOT be set to in
c/src/configure.ac to make it work? What variable has the top of the source
tree?

I guess $(top_srcdir)/../..?

Thoughts?



>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

2018-02-08 Thread Sebastian Huber 

On 08/02/18 16:08, Joel Sherrill wrote:


On Thu, Feb 8, 2018 at 3:05 AM, Sebastian Huber 
> wrote:


On 08/02/18 09:11, Sebastian Huber wrote:

On 08/02/18 01:00, Joel Sherrill wrote:

Hi

The patch was quite large and rightly blocked from being
sent to
everyone (~900k). Compressed, it is only 63K

This eliminates the custom directory and moves everything up
one level.  No failures in the build as shown here.

https://lists.rtems.org/pipermail/build/2018-February/000398.html



If we move this stuff, then why not to

bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make


OK. I can pick at that but what does from testsuites this change to?

include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg

Will RTEMS_ROOT need to change to something like $(top_srcdir)/...?

Is there a Makefile.am variable that really points to the top of the 
source tree?


The other common pattern is

include $(RTEMS_ROOT)/make/custom/default.cfg

in all the BSP .cfg files? What will that need to be to work before and
after install?

RTEMS_ROOT is the build tree and later the install point. I don't
know how to make that one work.

Any thoughts?


No user should be forced to touch its Makefiles only because we move 
some files in the RTEMS source tree from A to B. So, I think the install 
location should remain as is.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

2018-02-08 Thread Joel Sherrill 
On Thu, Feb 8, 2018 at 3:05 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/02/18 09:11, Sebastian Huber wrote:
>
>> On 08/02/18 01:00, Joel Sherrill wrote:
>>
>>> Hi
>>>
>>> The patch was quite large and rightly blocked from being sent to
>>> everyone (~900k). Compressed, it is only 63K
>>>
>>> This eliminates the custom directory and moves everything up
>>> one level.  No failures in the build as shown here.
>>>
>>> https://lists.rtems.org/pipermail/build/2018-February/000398.html
>>>
>>
>> If we move this stuff, then why not to
>>
>> bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make
>>
>>
OK. I can pick at that but what does from testsuites this change to?

include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg

Will RTEMS_ROOT need to change to something like $(top_srcdir)/...?

Is there a Makefile.am variable that really points to the top of the source
tree?

The other common pattern is

include $(RTEMS_ROOT)/make/custom/default.cfg

in all the BSP .cfg files? What will that need to be to work before and
after install?

RTEMS_ROOT is the build tree and later the install point. I don't
know how to make that one work.

Any thoughts?




> ?
>>
>>
> The corresponding ticket is:
>
> https://devel.rtems.org/ticket/3285


I thought I put that in the commit message


>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

2018-02-08 Thread Gedare Bloom 
On Thu, Feb 8, 2018 at 4:05 AM, Sebastian Huber
 wrote:
> On 08/02/18 09:11, Sebastian Huber wrote:
>>
>> On 08/02/18 01:00, Joel Sherrill wrote:
>>>
>>> Hi
>>>
>>> The patch was quite large and rightly blocked from being sent to
>>> everyone (~900k). Compressed, it is only 63K
>>>
>>> This eliminates the custom directory and moves everything up
>>> one level.  No failures in the build as shown here.
>>>
>>> https://lists.rtems.org/pipermail/build/2018-February/000398.html
>>
>>
>> If we move this stuff, then why not to
>>
>> bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make
>>
>> ?
>>
>
> The corresponding ticket is:
>
> https://devel.rtems.org/ticket/3285
>
+1

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

2018-02-08 Thread Sebastian Huber 

On 08/02/18 09:11, Sebastian Huber wrote:

On 08/02/18 01:00, Joel Sherrill wrote:

Hi

The patch was quite large and rightly blocked from being sent to
everyone (~900k). Compressed, it is only 63K

This eliminates the custom directory and moves everything up
one level.  No failures in the build as shown here.

https://lists.rtems.org/pipermail/build/2018-February/000398.html


If we move this stuff, then why not to

bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make

?



The corresponding ticket is:

https://devel.rtems.org/ticket/3285

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

2018-02-08 Thread Sebastian Huber 

On 08/02/18 01:00, Joel Sherrill wrote:

Hi

The patch was quite large and rightly blocked from being sent to
everyone (~900k). Compressed, it is only 63K

This eliminates the custom directory and moves everything up
one level.  No failures in the build as shown here.

https://lists.rtems.org/pipermail/build/2018-February/000398.html


If we move this stuff, then why not to

bsps/@RTEMS_CPU/@RTEMS_BSP_FAMILY@/make

?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Compressed patch to move make/custom/* to make/*

2018-02-07 Thread Joel Sherrill 
Attached this time.

On Wed, Feb 7, 2018 at 6:00 PM, Joel Sherrill  wrote:

> Hi
>
> The patch was quite large and rightly blocked from being sent to
> everyone (~900k). Compressed, it is only 63K
>
> This eliminates the custom directory and moves everything up
> one level.  No failures in the build as shown here.
>
> https://lists.rtems.org/pipermail/build/2018-February/000398.html
>
> --joel
>


0001-Move-make-custom-to-make-globally.patch.xz
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel