[PATCH v2 1/2] waf: Support building from libbsd.py directly from waf.

[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.

> 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?

>
> 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.

>
>> +        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