[PD-dev] cygwin port?
Hans-Christoph Steiner
hans at eds.org
Tue Sep 14 05:38:56 CEST 2004
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
More information about the Pd-dev
mailing list