Article discussing Go, could well be D

[Johannes Pfau]

Daniel Gibson wrote:
>Am 20.06.2011 10:52, schrieb Johannes Pfau:
>> Jacob Carlborg wrote:
>>> On 2011-06-19 21:59, Jose Armando Garcia wrote:
>>>> On Sun, Jun 19, 2011 at 4:19 PM, Jacob Carlborg<doob at me.com>
>>>> wrote:
>>>>> On 2011-06-19 19:02, Johannes Pfau wrote:
>>>>>>
>>>>>> I still don't understand that completely. So does it list the
>>>>>> files which will be contained in the package later, or file
>>>>>> dependencies contained in other packages?
>>>>>> (I'm asking because I'm not familiar
>>>>>> with file-dependencies in package management systems. Most
>>>>>> package management systems make a package depend on other
>>>>>> packages, but not on the files in the packages)
>>>>>
>>>>> Ok, let me explain. When developing a package management system
>>>>> the first thing one has do decide is if the package should contain
>>>>> pre-built binaries/libraries, we can call these binary packages,
>>>>> or the necessary files to build the package when installing, we
>>>>> can call these source package (not to be confused with the source
>>>>> type you've mentioned below). As a third option, one could have a
>>>>> mixed package system containing both binary and source packages.
>>>>> Maybe even mixed packages could be possible.
>>>>
>>>> Why decide on "file" package? This only works with packages that
>>>> can be compiled. Think non-D source code packages and close source
>>>> packages. Even one of the most commonly known "file" package
>>>> manager (Gentoo's portage) allows for binary packages.
>>>
>>> I guess we could have a mixed system, with both source and binary
>>> packages.
>> 
>> Definitely. Standardised source packages allow automated binary
>> package building, even for different architectures. Users should
>> also be able to make small changes to source packages and create
>> their own binary packages easily. Source packages only wouldn't work
>> either, think of users on embedded systems. Compiling everything on
>> a machine with 16MB ram and 200mhz isn't fun. Also binary packages
>> are quite convenient.
>> 
>
>1. Will you develop or compile your own software (that uses software
>from the package manager) on the embedded system? I guess it's more
>common to develop the software on a PC or whatever and upload it to the
>embedded system.

Maybe I misunderstood something, but I thought orbit will also manage
shared libraries once supported by the d compilers. Even on resource
limited embedded systems it's likely that a library is needed by more
than one program, so it can't really be shipped with the program. Static
libraries, documentation and d headers are not needed on these
platforms. Of course package managers for embedded systems (something
like openembedded) can be used, but then all libraries have to be
packaged again into a different package format.

>2. Will an embedded system with such restricted resources have a x86
>arch - or will it more likely be ARM or even something completely
>different? Should there be binaries available for any architecture
>(that's hard, because most developers probably only have x86/amd64)?
>If not, you'd have to compile yourself anyway.
>(And of course we need a working compiler for that architecture first)

Arm, mips (popular in internet routers), sh4 (settop boxes), ppc

Ideally we'd have a package build system like launchpad: The developer
(or packager) creates a source package, uploads it to the build service,
build service transfers the source package to buildbot machines, those
build binary packages for different architectures. The binary packages
are then added to a repository. We won't have something like that from
the beginning, but in a few years such a build service might be useful.

>Cheers,
>- Daniel


-- 
Johannes Pfau