[M3devel] more Debian packages?

[Jay]

No no no.
We will not have an explosion of targets like this. We hopefully will have a drastic reduction.
Processor: C or C++
Threads: pthreads or Win32 or maybe ucontext or setjmp
GUI: X Windows or Win32 or none or maybe other
Suspension: cooperative and probably no other


If the right level of #ifdef and/or autoconf and/or libtool use can makes its way into the "object code", maybe just target completely. (imagine one C source distribution for ALL targets and what that requires).
We have rather replaced autoconf & libtool with our carefully researched & written quake code, for better & worse & I am torn as to if this is a good thing. Autoconf & libtool are slow & obscure but ubiquitous, get the job done, are actively maintained by others.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 19, 2012, at 11:32 AM, "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> wrote:

> Hi all:
>  I would want LINUX_I80_8Y or if you prefer LINUX_I_8Y,
> for instance to allow and or LINUX_I8086, etc LINUX_I387 
> For VAXen computers:
> VMS_VAX__
> for VAX Mini/Mainframe VMS_VAX9K or VMS_VAX11
> Alpha's: OSF_ALPHA
> For Unixes:
> FBSD-GENERIC_I_86___--
> To allow: FBSD-2_I386.MAX, OBSD-6_I_86.AMD64
> Also could be managed by Manufacturer Model code-name, like
> DEC_AQUARIUS or DEC_10000.
> 
> Also if we are gonna take macro assembly for cross-platform distributions then, we would need  something akin:
> NT_XASM-I_86___
> So to cross-assembly from C-RT to POSIX interoperability NT-I_86GNU (if such is supported in any appropriate version, Jay)
> 
> This would allow to compile CVSup at least is what one would like to
> Thanks in advance
> 
> --- El vie, 18/5/12, Jay K <jay.krell at cornell.edu> escribió:
> 
> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] more Debian packages?
> Para: hendrik at topoi.pooq.com, "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 18 de mayo, 2012 16:50
> 
> Yes and yes.
> LINUXLIBC6 and AMD64_LINUX can coexist -- different targets can coexist.
> But "squeeze" vs. "wheezy" will both just be LINUXLIBC6.
>  
>  
> Please try to use I386_LINUX.
> I really want to stop this LINUXLIBC6 stuff...
>  
>  
>  You can share the source.
>  But we also have outputs in the source tree (unfortunately!).
>     You see -- Modula-3 build system ahead of its time at the time in putting each package's output separate from the source, but that is now not uncommon, and Modula-3 then falls down because at least by default, a multi-package source tree contains its outputs... Modula-3 does things better than most folks at the time, and now worse than everyone knows is ideal and that some folks do...
>  
>  
>  Do this to switch:
>  
>  ./do-cm3-all.py realclean 
>  
>  - Jay
>  
> > Date: Fri, 18 May 2012 16:56:49 -0400
> > From: hendrik at topoi.pooq.com
> > To: m3devel at elegosoft.com
> > Subject: [M3devel] more Debian packages?
> > 
> > Having succeeded at producing a binary .deb packages for Debian squeeze 
> > (though I still have to try it out), I'm now looking at my other 
> > machines. I have a 32-bit Intel machine with wheeze (testing), and one 
> > that can run squeeze (stable). All of them have access to the same 
> > NFS-mounted source tree. Is it practical to use the same tree for two 
> > different platforms (such as AMD64_LINUX and LINUXLIB6?) and will they 
> > be kept separate? Or do I need to clean it out or copy it?
> > 
> > (by the way, I expect making packages for different Debian releases on 
> > the same hardware architecture will require a new source tree, or a 
> > cleaned-out one. In my case they'll both be LINUXLIBC6)
> > 
> > -- hendrik
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/5fe49c86/attachment-0002.html>