[En-Nut-Discussion] Anyone ever compiled contrib/arm-crypto-library?
ole.reinhardt at embedded-it.de
Wed Oct 30 09:39:58 CET 2013
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
> No, this is no real problem right now, but adding the contrib path now
> may provide problems when adding more contribs in the future.
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
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.
kernel concepts GmbH Tel: +49-271-771091-14
Sieghuetter Hauptweg 48 Mob: +49-177-7420433
More information about the En-Nut-Discussion