10 years, 6 months ago.

Why am I seeing uncommitted changes to EthernetInterface after I've imported it?

If I create a new program and import the mbed-official EthernetInterface, then the EthernetInterface immediately shows uncommitted changes of: Socket.lib, lwip-eth.lib, lwip-sys.lib & lwip.lib. In contrast after importing mbed-rtos or mbed-rpc there are no uncommitted changes on those libraries.

Because of the uncommitted changes on EthernetInterface, I can't commit my new program without first committing the changes to EthernetInterface which surely I don't want to do.

Am I supposed to fork EthernetInterface or what?

The changes reported are (tedious as you can't copy from the online compiler in Revisions-Changes web page):

You aren't the first one with this problem, mbed staff should indeed look at it.

posted by Erik - 30 Sep 2013

1 Answer

-deleted-
10 years, 6 months ago.

Hi Richard,

Thanks for reporting this. We are aware of the issue and our team is working on it.

The problem is that Socket, lwip-eth, lwip-sys and lwip libraries are referenced without hash in EthernetInterface library, which makes it impossible for the Online IDE to track the revision dependency between the program, libraries and sub-libraries.

Why is this important? Libraries and APIs are often changed and rewritten in favor of more efficient code, better structure, etc. If there is no dependency tracking between your program and the sub-libraries in EthernetInterface then your program might render uncompilable in a scenario where the APIs/classes/methods of the sub-libraries are changed in non-compatible way to your program in a year or more from now.

What the Online IDE does is to ensure that the state of your code is preserved exactly as it is in your workspace - program, libraries, sub-libraries, all of it - and let you (and everyone else if published as public) to restore at any given moment to any given revision. The lack of hashes in the .lib files that are internal to the Online IDE, prevents it from ensuring that you can do that and logically it attempts to correct the issue by adding the current hashes of the sub-libraries. This on other hand introduces changes in EthernetInterface library itself and given that you can't publish to it you are forced to fork the library. If a member from our team imports the library in their workspace, commits the uncommitted changes and publishes, then this will be fixed for everyone. But until then -

Solution: Until then a quick solution is to revert to revision 31 of the EthernetInterface library, which contains the proper references to the sub-libraries. This won't require committing and forking.

UPDATE: This is now fixed against the official EthernetInterface library. Just update to the latest revision

Cheers,
Mihail

Accepted Answer

Thanks for fixing this

posted by Richard Care 01 Oct 2013