External Libraries and Headers for eLua

[Kevin Vermeer]

On Tue, Feb 22, 2011 at 1:12 PM, Bogdan Marinescu <[hidden email]> wrote:

>> 0.8 seems like another disaster release, like 0.7 which didn't even
>> compile for EVK1100.

Actually it did, but for an older version of the Atmel tools (headers
and libraries); the newer library used a different API. This is what
you get when dependencies such as headers and libraries are not part
of the project. I think AVR32 is currently the only eLua target that
has external dependencies. But yes, ATEVK1100 built just fine, the
best proof is the ATEVK1100 binary image that is part of the 0.7
release.

Bogdan, you brought up a point which I thought merited forking the discussion.

You wrote that the AVR32 port is currently the only eLua target that has external dependencies.  You may soon have two such projects; the PIC32 port I'm working on will be most quickly accomplished if we use the Microchip libraries and headers. 

Unfortunately, these libraries and headers include a lot of different license agreements; both MIPS copyrights and Microchip copyrights are asserted.   If we work on the assumption that including them in the repository is not legally possible, then it seems that we're restricted to an external dependency (which seems to have caused problems for the AVR32 port already), or re-writing them from scratch (which would slow the process down significantly). 

Aside from the two comments above, how well has the AVR32 port with its external dependencies worked?

If the answer to the above wuestion isn't "Fantastic!" (and I doubt it is), then is it legally possible to include the PIC32 libraries and headers in eLua's source?

I've attached the file MPLAB_C32_Compiler_License.rtf, which is distributed with the Microchip PIC32 toolchain, to help answer these questions.   It covers the software (I'm not sure if that includes the source code) and documentation.  The files themselves include a wide variety of BSD, GPL, modified BSD, Microchip, and MIPS licenses.  Ugh. 

Thanks,
--
Kevin Vermeer

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Wed, Feb 23, 2011 at 12:05 AM, Kevin Vermeer <[hidden email]> wrote:
> Bogdan, you brought up a point which I thought merited forking the
> discussion.
>
> You wrote that the AVR32 port is currently the only eLua target that has
> external dependencies.  You may soon have two such projects; the PIC32 port
> I'm working on will be most quickly accomplished if we use the Microchip
> libraries and headers.

Yes, that would be the second target with external dependencies.

> Unfortunately, these libraries and headers include a lot of different
> license agreements; both MIPS copyrights and Microchip copyrights are
> asserted.   If we work on the assumption that including them in the
> repository is not legally possible, then it seems that we're restricted to
> an external dependency (which seems to have caused problems for the AVR32
> port already), or re-writing them from scratch (which would slow the process
> down significantly).
>
> Aside from the two comments above, how well has the AVR32 port with its
> external dependencies worked?
>
> If the answer to the above wuestion isn't "Fantastic!" (and I doubt it is),

I believe Martin has responded to that already :) I do have something
to add though: this is mostly my fault. This model should work well as
long as the specific version of the external
libraries/headers/whatever used to built eLua are clearly specified
inside eLua. Even if they change the API might stay the same. What
happened to AVR32 was an unfortunate incident and we learnt a few
things from it. Mainly this one: specify the version of the external
tools eLua uses to compile itself inside eLua.

> then is it legally possible to include the PIC32 libraries and headers in
> eLua's source?

I seriously doubt.

> I've attached the file MPLAB_C32_Compiler_License.rtf, which is distributed
> with the Microchip PIC32 toolchain, to help answer these questions.   It
> covers the software (I'm not sure if that includes the source code) and
> documentation.  The files themselves include a wide variety of BSD, GPL,
> modified BSD, Microchip, and MIPS licenses.  Ugh.

Thank you, but I'm not even going to try to read it since I will not
be able to understand it. I tried to understand lawyerish before and
failed miserably. It's simply not my language. From what I could
gather though I don't think t we can include any part of the Microchip
toolchain in eLua. But once again, this shouldn't be necesary for the
reasons outlined above.
To recap: please continue working on porting eLua using the tools from
Microchip, but start from the asumption that we won't be able to
include any of these tools inside eLua. It's our job to take care of
the rest in a manner that is as painless as possible. The most elegant
solution that I have in mind is to add an explicit 'external_deps'
target to the new build system that will show the external
dependencies of the project. Something like this (off the top of my
head):

$ lua build_elua.lua board=pic32whatever external_deps
The PIC32 build of eLua depends on the following 3rd party tools:
- compiler version(s) : x, y, z
- Microchip packge version(s) : x, y, z
- libraries version(s) : x, y, z

Make this as verbose as possible so people will understand what's
going on. Checking the tool versions automatically is even a nicer
idea but it might not be worth the trouble.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev