Am 10.08.2017 um 08:31 schrieb Chris Johns:
> On 10/08/2017 16:06, Christian Mauderer wrote:
>> Am 10.08.2017 um 07:55 schrieb Chris Johns:
>>> On 10/08/2017 15:34, Christian Mauderer wrote:
>>>> Am 10.08.2017 um 01:08 schrieb Chris Johns:
>>>>> On 10/08/2017 02:29, Sichen Zhao wrote:
>>>>>> From: Christian Mauderer <>
>>>> There was no real reason. I just chose an arbitrary name.
>>>> 'build-include' is fine for me too. I would avoid just 'include' because
>>>> it's a very generic name. If it is added somewhere else, that might lead
>>>> to a conflict.
>>> Ah yes, 'build-include' is fine.
>>>>>> +        start_dir = bld.path.find_dir(headers[0])
>>>>>> +        for header in start_dir.ant_glob("**/" + headers[1]):
>>>>> Do we always want to copy all the files?
>>>> What do you mean by "all the files"? As far as I understood, only the
>>>> files that are changed should be copied by waf.
>>>> Or do you mean the ant_glob? In that case: I modeled that after the
>>>> install target of the headers. 
>>> Should this be an ant_glob or a list? I am wondering about needing to copy a
>>> selected number of files from a group a glob would catch. If this is not
>>> happening that is fine, it can be added if the situation arises.
>> Oh, I think I start to understand what you mean. Like already said, this
>> works around the problem that the headers are not installed when the
>> sources are built. So it should definitely should copy the same files
>> like the install part that also uses that array.
> Agreed.
>> It is possible to add a glob which catches only a single file (even
>> better if we move the "**" into You might have noted that
>> Sichen had to add a lot of such lines for openssl. It would be nice to
>> have some cleaner method of writing that but I haven't found one yet.
> Yes I had noticed it is a large package. Is the number of files in the 
> module the concern? There is a point of view that says explicit listing of 
> files
> is better because you do not accidentally pick up files you should not where
> glob'ing a tree in or could do that.

I was more concerned that the include list in has grown
significantly. If you don't have a problem with that, it's OK.

> The include lists in was something I knew would come back and bite
> me. There was only so much I could do at the time and this fell of the end. I
> thought the list might grow but could not see a real use case. I can fix this
> once the patch is merged.
>> Maybe you have an idea?
> Not at the moment. Lets get this work in and then I can take a look. It will 
> be
> simpler and also clearer to see what is happening.
> I could look at making into libbsd/ with a file per 
> module
> and the top level just sees the imports. I still see no need for us to have
> module build control, we always build all modules.

Currently I wouldn't see a big advantage in splitting up
except that the files are smaller.

It might would be nice to have some more control over the modules that
get build with some kind of configuration or BSP-config file in the
future. If it would be possibility to set custom defines depending on
the configuration that would even add some more flexibility. With that
it would for example be possible to exclude IPv6 support on small
targets or add a BSP specific driver. But that's a problem that can be
solved some when in the future when someone in the community has time or
budget to do that.

>>>>> If a new field is not added can you please update with this 
>>>>> rule so
>>>>> we know what to do when adding headers to builder.headerPaths()?
>>>> You mean some comment that describes that behavior? I can add that also
>>>> I don't really think that it is necessary. It's just a workaround so
>>>> that we can build the binaries without having to install the headers
>>>> before the build.
>>> It took me a while to see what was happening. The table in is a 
>>> long
>>> way from here so even a note would help.
>> OK. I'll add a comment that shortly describes what happens with the list
>> of header files.
> Thanks.
> Chris

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
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

Reply via email to