[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: pict



Hi Ralf

Ralf Treinen wrote:
> Hi,
> 
> On Wed, Feb 21, 2007 at 06:45:55PM +0100, Matej Kosik wrote:
> 
>> Is there a way how could I try to compile this package for all
>> architectures and see if everything works? I must admit, I am working on
> 
> Sort of, if you are a debian developer. There are debian
> machines for all supported architectures where dds can login,
> but this would mean of course compiling and testing "by hand".

Good to know. I just have asked to be sure I did not overlooked such possibility (if it existed).

> 
> One could use the the autobuilder network, maybe at first for 
> the "experimental" architecture if one has serious doubts that
> everythings works on every architecture.

From the `INSTALL' file
<CITE>
Pict has been compiled successfully on these platforms:
   - Sun Sparc   (SunOS and Solaris)
   - 486/586     (Linux)
   - DEC Alpha   (Ultrix)
</CITE>
I myself has tried to compile it on Debian GNU/Linux
(and fixed one problem and reported it to the original developers)
Neither compiler nor binaries created by the Pict compiler use any hardware-specific feature. Actually, very little additional functionality is needed (like some libc functions such as memcpy, memset, malloc, free) and the binaries created by the Pict compiler do not need any operating at all and can run in kernel mode (this is what I tried). Pict is the simpliest capability-secure language I have seen (although my view might not be very broad). So in this respect it is interesting (even though many things could be improved on the original package, but I did as little changes as possible so that it can still be called Pict). Capability security is very interesting and Debian GNU/Linux does not contain any programming language that would support it. (I might be wrong, though). This is partially why I submitted this package. The advantage of Pict over other capability secure languages I know (such as E www.erights.org) is that it can be directly compiled with free software tool
s which are directly part of Debian GNU/Linux.

> 
>> i386-compatible and the binaries I have created are also for this
>> architecture. I think it would be too bold to say `any' if I have
>> actually only tried `i386'. How do others try their packages on "other
>> architectures" that whose instances they physically own?
> 
> It depends on the case. In many cases you can reasonably expect that if
> your package compiles and runs on one architecture then it is the
> same on the other architectures. In other cases you can expect right
> from the beginning difficulties. You as a package maintainer should
> have some idea about this, if necessary by looking at critical
> portions of the code, or sometimes from the compiling instructions
> given by upstream.
> 
> I guess that many developers just upload and then wait for bug
> reports, or look at the buildd logs. But it is of course much
> better to think of it in avance.
> 
> -Ralf.

If there is no better way on what architectures Pict works without problems, I would risk and do the same as more other people before me. It is always possible to fix problems later if some arise. In the worst case Pict could be declared as software solely for `386' but I think it will work also elsewhere.
-- 
Matej Kosik

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: