Am 26.03.2018 um 13:45 schrieb Chris Johns:
> On 26/3/18 9:08 pm, Christian Mauderer wrote:
>> Hello Chris,
>>
>> thanks for that great support for #3351. Like I already said there, I
>> started to work on something similar on Friday. But your solution is
>> quite a bit advanced compared to mine one. I haven't started to move any
>> configuration yet.
>
> I hope I did not waste any of your time.
I put a few hours into it. But on the other hand it has been quite
useful to understand what you did with this patch and it will be useful
for the rest of the ticket. So no problem there.
>
>> This patches will make it a lot easier to understand and maintain the
>> build system.
>
> I think so. We now have a clear separation of the source side and the
> build side all using the same build data from libbsd.py and that is nice.
>
>> While looking at the patches, I noted that they don't apply on master
>> but only a few patches behind it. But I think that shouldn't be a big
>> problem.
>
> I am sorry, I did not rebase before posting.
>
>> I added a few comments for the waf_libbsd.py in the (shortened) patch
>> below.
>>
>> If you want, I can have a look at the documentation files (libbsd.txt,
>> README.waf, ...) and update them with this new information.
>
> Sure, or should we wait until we have the configuration side sorted?
Both is possible. Maybe you are right that it is a better idea to do
that after the configuration side is done too. Otherwise a lot of it
will be re-written multiple times. I'll keep that on my list for that
project.
>
>>
>> Best regards
>>
>> Christian
>>
>> Am 26.03.2018 um 06:14 schrieb Chris Johns:
>>> Remove the need to generate a waf script.
>>>
>>> Move various pieces of data from the builder code to libbsd.py and make
>>> it configuration data.
>>>
>>> Update #3351
>>> ---
>>> builder.py | 158 +--
>>> freebsd-to-rtems.py | 18 +-
>>> libbsd.py | 319 ++++--
>>> libbsd.txt | 13 +-
>>> libbsd_waf.py | 3084
>>> ---------------------------------------------------
>>> waf_generator.py | 693 ------------
>>> waf_libbsd.py | 645 +++++++++++
>>> wscript | 28 +-
>>> 8 files changed, 919 insertions(+), 4039 deletions(-)
>>> delete mode 100644 libbsd_waf.py
>>> delete mode 100755 waf_generator.py
>>> create mode 100644 waf_libbsd.py
>>>
>>
>> [...]
>>> diff --git a/waf_libbsd.py b/waf_libbsd.py
>>> new file mode 100644
>>> index 00000000..8f5340ba
>>> --- /dev/null
>>> +++ b/waf_libbsd.py
>>> @@ -0,0 +1,645 @@
>>
>> [...]
>>
>>> +
>>> + #
>>> + # Include paths
>>> + #
>>> + includes = []
>>> + if 'cpu-include-paths' in config:
>>> + cpu = bld.get_env()['RTEMS_ARCH']
>>> + if cpu == "i386":
>>> + cpu = 'x86'
>>> + for i in config['cpu-include-paths']:
>>> + includes += [i.replace('@CPU@', cpu)]
>>
>>
>> I'm not sure whether that does the same as before. In the old
>> libbsd_waf.py that looked like follows:
>>
>> for i in ['-Irtemsbsd/@CPU@/include', '-Ifreebsd/sys/@CPU@/include']:
>> includes += ["%s" % (i[2:].replace("@CPU@",
>> bld.get_env()["RTEMS_ARCH"]))]
>> if bld.get_env()["RTEMS_ARCH"] == "i386":
>> for i in ['-Irtemsbsd/@CPU@/include',
>> '-Ifreebsd/sys/@CPU@/include']:
>> includes += ["%s" % (i[2:].replace("@CPU@", "x86"))]
>>
>> So for the i386 we had i386 and x86 paths. Now we only have x86 paths.
>> Is that really correct?
>
> Hmm I do not know. I did wonder. I will build a PC BSP tomorrow and see
> what happens.
>
>>
>>> + if 'include-paths' in config:
>>> + includes += config['include-paths']
>>> + if 'build-include-path' in config:
>>> + includes += config['build-include-path']
>>> +
>>> + #
>>> + # Collect the libbsd uses
>>> + #
>>> + libbsd_use = []
>>> +
>>> + #
>>> + # Network test configuration
>>> + #
>>> + if not os.path.exists(bld.env.NET_CONFIG):
>>> + bld.fatal('network configuraiton \'%s\' not found' %
>>> (bld.env.NET_CONFIG))
>>> + tags = [ 'NET_CFG_SELF_IP',
>>> + 'NET_CFG_NETMASK',
>>> + 'NET_CFG_PEER_IP',
>>> + 'NET_CFG_GATEWAY_IP',
>>> + 'NET_TAP_INTERFACE' ]
>>
>> The NET_TAP_INTERFACE is unused and wouldn't even work in the old python
>> code or in this one because it doesn't start with 'NET_CFG_'. The patch
>> that I recently sent has removed it.
>
> Oh of course, I am sorry please remove.
I think on a rebase that would have popped up anyway.
>
>>
>>> + try:
>>> + net_cfg_lines = open(bld.env.NET_CONFIG).readlines()
>>> + except:
>>> + bld.fatal('network configuraiton \'%s\' read failed' %
>>> (bld.env.NET_CONFIG))
>>> + lc = 0
>>
>> [...]
>>
>>> + #
>>> + # Installs.
>>> + #
>>> + # Header file collector.
>>> + #
>>> + arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
>>> + bld.env.RTEMS_ARCH_BSP)
>>> + arch_inc_path =
>>> rtems.arch_bsp_include_path(bld.env.RTEMS_VERSION,
>>> +
>>> bld.env.RTEMS_ARCH_BSP)
>>> +
>>> + bld.install_files("${PREFIX}/" + arch_lib_path, ["libbsd.a"])
>>> +
>>> + if 'header-paths' in config:
>>> + headerPaths = config['header-paths']
>>> + cpu = bld.get_env()['RTEMS_ARCH']
>>> + if cpu == "i386":
>>> + cpu = 'x86'
>>
>> I'm not really sure here: Are you sure that this is the same behavior
>> like before? I think we had two paths for i386 before.
>
> Yes, I repeated the same thing. Maybe a helper method is needed to
> handle this and used in both places?
>
> Thanks for the review.
>
> Please feel free to correct, change and commit when you are happy.
>
> I will now leave this task for you to complete the configuration side if
> that is OK?
>
> Chris
Yes of course I will do the configuration side. We already discussed
that I have the time for that in a project. To be honest: I was already
quite positively surprised that you did these patches. I'll keep you up
to date with the progress.
I could work on a branch for the changes but it maybe would already be a
good idea to update and push these two patches (I can do that) so that
they don't get out of sync with the libbsd. They are already a great
step. Of course that might leaves the documentation in a work in
progress state till I do the configuration work (like discussed above).
What do you think?
Best regards
Christian
--
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
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
