[PD-dev] cygwin port?

[Reini Urban]

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 :)

> 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.

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/