[Openembedded-architecture] Proposal: dealing with language-specific build tools/dependency management tools

[Mark Hatle]

On 3/13/17 1:28 PM, Trevor Woerner wrote:
> On Sat, Mar 11, 2017 at 4:25 PM, Trevor Woerner <twoerner at gmail.com> wrote:
>> Here is a link to a talk given at the most recent linux.conf.au given
>> by someone who works at SuSE doing package management discussing
>> essentially the same things:
>>
>> https://www.youtube.com/watch?v=4ua5aeKKDzU
>> Package Managers all the way down
> 
> In case you haven't had a chance to watch this video I wanted to point
> out some of the items that jumped out at me that I think are relevant:
> 
> - First off, remember this person isn't involved in OE/Yocto, but
> distribution package management in general. Maybe we need to reach out
> to other such people involved in similar activities across more Linux
> distributions? Maybe some answers are already out there?
> 
> - Almost all "new" languages think they need to solve the
> package/dependency issue internally. However, most of them get it
> wrong and will take a while before all corner cases are handled
> properly.
> 
> - Traditionally putting together a Linux system involved
> (cross)compiling a bootloader, Linux kernel, and userspace. Most of
> which, _traditionally_, was written in C/C++. This meant the same
> tools and procedures could be used for building the "base system"
> versus the "user-space apps". Maybe this is changing. Maybe we need
> different tools or procedures depending on whether we're building the
> base system versus the user-space. In other words, Henry just pointed
> out how "npm install" doesn't fit into the OE model of "fetch, patch,
> configure, build, deploy". Maybe that's because that model needs to be
> abandoned when building these apps (but can be retained for
> "traditional" code)?

Remember the model of fetch, patch, configure, build, (install), deploy,
(sysroot/sstate cache ones) is just default.  You can create your own model by
removing those tasks and defining new ones.

My understanding is the only ones that really matter are the 'fetch' (have to
get it 'somewhere', and the deploy steps..  everything else can and should be
variable if necessary.

This issue that I see though is OE expects 'one' source per recipe.  Where many
of these new systems have multiple sources to product multiple outputs.  So the
1:n mapping really becomes m:n, and that is something that is difficult for what
we have today.

> - This "new model" is not limited to "new" languages. The C/C++
> community is jealous ;-) of this new model and some are looking to
> adopt it for these traditional languages as well! See
> https://conan.io/

(I'm weeping right now... as Nancy Reagan said "Just say No!")

--Mark

> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>