Should we consider separating *only* the shared header definitions and APIs into a separate "shared" folder which would be accessed by the ARM compiler and host compilers from *all* Osmocom related projects?<div>
<br></div><div>I've been porting the code to Windows and can see the benefits of clear separation of code.<br><div><br></div><div>B.</div><div><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 5:39 PM, Harald Welte <span dir="ltr"><<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Jan 21, 2013 at 10:51:53AM +0100, Sylvain Munaut wrote:<br>
> The host build was becoming a problem and that's why it was moved out.<br>
> The target build has not caused issue so I don't see why we would<br>
> change it and give it the opportunity to fail.<br>
<br>
</div>btw, just for the record: the idea of the host build from inside<br>
osmocom-bb.git was to make sure that the header files and APIs on both<br>
sides would be identical, which was considered a helpful idea if more<br>
and more code is eventually moved from host into the target (which never<br>
happened so far).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>>           <a href="http://laforge.gnumonks.org/" target="_blank">http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
                                                  (ETSI EN 300 175-7 Ch. A6)<br>
<br>
</font></span></blockquote></div><br></div></div>