[PD-dev] cygwin port?

[Hans-Christoph Steiner]

On Sep 13, 2004, at 12:00 PM, Reini Urban wrote:

> Hans-Christoph Steiner schrieb:
>> Anything to make installing Pd easier will only serve to expand the   
>> user base.
>
> do you want that, or do your prefer an expanded developer base only :)

Both are good. Expanded developer base means more work done on Pd.   
Expanded user base means more people to answer the basic questions, and  
more people to hopefully contribute a little money to the developers so  
that can feed, house, and clothe themselves working on Pd.

>
>> Cygwin has functional symbolic links, so that would mean  that all  
>> platforms that Pd runs on could use symbolic links for object  alias  
>> names when libraries are compiled as individual objects.
>
> yes. but dll's unfortunately cannot be symlinks, because a PE exe  
> locates the dll name from the PE header and searches just the usual  
> dll LibrarySearchPaths, but doesn't resolve symlinks.
> I'll try to add that delayed lazy loading somewhen to the gcc linker  
> (wine and the msvc linker has it already), but for that I would need  
> for more time.

Ah, that's a bummer for sure.  It would be great to be able symlink  
.dlls because they we would have a complete cross-platform solution for  
organizing Pd objects.  Any work towards that goal would be greatly  
appreciated.

.hc


> pd files can be symlinked.
>
> just for the records.
>
>> my two cents...
>> .hc
>> On Sep 13, 2004, at 9:18 AM, Reini Urban wrote:
>>> cdr schrieb:
>>>> On Mon, Sep 13, 2004 at 12:15:51PM +0200, Reini Urban wrote:
>>>>
>>>>> Nobody looked so far at a cygwin port?
>>>
>>>
>>>> besides ideological issues, NT kernel only misses shmget() stuff and
>>>> fork(). just add a few #define or rewrite a few lines is all it  
>>>> takes  to
>>>> avoid the 75% overhead of cygwin.
>>>
>>>
>>>> well SDL doesnt support video input (yet?) so on NT you are
>>>> output-only if you build pdp or gridflow - maybe you're interested  
>>>> in
>>>> developing some sort of abstracted directshow input-layer to be  
>>>> hooked
>>>> into pdp and gridflow all at once - theres possibly-useful code in  
>>>> GEM
>>>> already.
>>>
>>>
>>> Good and not that hard. We already have some DSH input/output-layer   
>>> for xvid, for which I do nightly mingw snapshots.
>>>
>>>>> I see various build targets, which would help.
>>>>> pd_cygwin would be a merge of pd_linux and some pd_nt (just the   
>>>>> dllext and some makefile additions, using a newer libtool to use   
>>>>> dlltool and maybe dllwrap)
>>>>> FYI, cygwin supports OOTB tcl/tk (native nt) and opengl (native or  
>>>>>  x11).
>>>>> And sound should be possible also in a mixture of linux and nt   
>>>>> manner (/dev/dsp wrappers and WinAPI).
>>>
>>>
>>>
>>>> install msysDTK (autoconf/CVS/openSSH/perl) and a shortcut like:
>>>
>>>
>>> please not. I prefer real compatibility.
>>>
>>>> C:\m\bin\rxvt.exe -fn "lucida console-10" -sl 10000 -e bash --login  
>>>> -i
>>>> and you should see why cygwin isnt necessary - if you want to make a
>>>> dpkg repository, that would be great..it is annoying to grab source  
>>>>  from
>>>> 50 places, reminds me of slackware..,
>>>
>>>
>>> we had dpkg support before. I wonder where this went. This might be  
>>> an  option, but setup.exe requires pure tar.bz2, with some automatic  
>>>  preinst and postinst scripts in /etc/
>>>
>>>>> The packaging would be similar to debian.
>>>>> I'd prefer cygwin over MSVC, or at least mingw. But if you already  
>>>>>  support MSVC, mingw is straightforward.
>>>>>
>>>>> when is cvs.sf.net populated? I prefer to update from cvs, than  
>>>>> from  tar.gz. I miss gem, extensions, ...
>>>
>>>
>>> I see. gem is somewhere else at sf.net.
>>>
>>>>> It would be nice to have this finished for the convention.
>>>>> I'm already thinking of maintaining apache, php and postgresql for  
>>>>>  cygwin, so puredata would be not so problematic to maintain for  
>>>>> me,  compared to the others.
>>>>
>>>> co -r devel_0_37 pd, use makefile.mingw. it is stil not in   
>>>> configure.in, if you feel like taking a stab at that..
>>>
>>>
>>> mingw is technically fine (besides it has no ipc layer).
>>> The main cygwin advantage would be a wide audience, since
>>> cygwin comes with an easy package manager: setup.exe
>>>
>>> and it would be similar to the debian package:
>>> one click install of a lot packages.
>>>
>>> another minor problem:
>>> cygwin ships with tcl84, pd has 83 bundled. we would use 84.
>>> any technical problems why you didn't switch to 84 yet?
> -
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>

________________________________________________________________________ 
____

"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away
to benefit those who profit from scarcity."
							-John Gilmore