[En-Nut-Discussion] Anyone ever compiled contrib/arm-crypto-library?

[Ole Reinhardt]

Hi Harald,

Am 29.10.2013 13:28, schrieb Harald Kipp:

> You modified two things:
> 
> First you changed the preprocessor include statements. That would
> require patching each update, but, as I wrote in my previous post, that
> is acceptable for me.

Ok. Yes, that's true.

I even thought about something else:

What about placing the contrib includes along with the contrib sources
and not place them to nut/include/contrib?

This way we could add an $I param for each selected contribution to the
CFLAGS, as soon, as the contrib is selected in the confgurator?

And we would not need to define long #include statements in the code?

In my eyes this would give a more clean repository structure.

> Second you added "$(INCPRE)$(top_srcdir)/include/contrib" to some
> Makedefs. This however is dangerous. It may unintentionally add non-BSD
> code to an application. I think it is more important to help users to
> keep their code BSDL-clean than to help them adding GPL'ed code.

Would it? Adding the nut/include/contrib to the CFLAGS does not add a
single header file to the compiled code. It just adds a search path.

You still have to add the header file to your code manually.

> To clarify:
> 
> Yes, header files contain licensed code. (Just in case this is not clear
> to everyone.)

Yes for sure :-) I agree, that we should not add header files with
non-BSD license to our projects automatically. As mentioned above addind
a search path does not add headers to your project :)

But only bad coded header files will leave any code in your final biary,
as long as the contents are not referenced anywhere else in your
application ;-)

> No, this is no real problem right now, but adding the contrib path now
> may provide problems when adding more contribs in the future.

Ok!

So whatr about my suggestion above to no add any contrib headers to
nut/include/contrib at all and place them always along with the contrib
sources?

Further It might be a good idea to not create makefiles for the
contributed code by the configurator at all, but place a Makefile in the
contrib directory, which then can just be called by a make -C
nut/contrib/... statement from the main makefile?

I'm just thinking about szenarios, where someone likes to add a third
party library to the contributions, which comes with it's own makefile.
(I'm currently thinking about zlib, which I just wantete to add there).

Using the provided Makefile instead of creating an own with the
configurator would keep things more clean in my eyes.

Bye,

Ole

-- 
kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48         Mob: +49-177-7420433
D-57072 Siegen
http://www.embedded-it.de
http://www.kernelconcepts.de