[PD] building all external on linux

[=?X-UNKNOWN?Q?g=FCnter_geiger?=]

On Tue, 12 Apr 2005, IOhannes m zmoelnig wrote:
> what makes structuring code as libraries vs. singular externals a "key
> to collaboration" ?

I think it just makes it easier.
+ to avoid nameclashes
+ to have a common build system
+ to make a list of existing externals
+ to make the build system resistant to errors in single externals
+ to come up with a common consistent set of externals
- make it hard to share code

wheras libraries
- make it hard to find out which externals they contain
- obscure nameclashes
- fail to build if one single external doesnt build
- have to be loaded explicitly by the user
+ make it possible to share code between different objects

Therefore I think it would be better to have single externals in all
cases where there is no shared code. I understand that this point of
view is not shared by the other developers, I just based my decisions
2 and a half years ago on that, and that is how I explained it.

I think this enabled a very simple, robust and easy to maintain build
system.

Guenter


> i mean, i cannot collaborate better or worse just because a bunch of
> c-files are compiled into one binary or because one c-file compiles into
> a bunch pd-objects.
>
> >
> > imagine the linux kernel would be like pd, in order to get my
> > network card running, i would have to load the coxlib, except for
> > the eepro card, which is in the libthorvalds, which currenlty doesn,t
> > build because of a typo in the rtl module.....
>
> which is basically like it is ;-)
> to get my network card running i have to use 8139too.ko except for my
> wlan-card where i have to use ndiswrapper, which currently doesn't work
> because even windoze has no 64bit drivers for it.... (of course, we can
> blame broadcom to not give away there specs in the first place, but it
> still doesn't work)
>
> to get you more involved: i have to compile the realtime-lsm module in
> order to make pd/gem work with chromium with -rt.
>
> and most probably there is also a weird (void*)-cast error in the
> eepro-code of libthorvalds (although i didn't get there because of the
> typo in the rtl)
>
> >>- it doesn't handle flext externals
> >
> > flext has its own build system. its not the goal to handle this
> >
> >>- it doesn't handle special compile time flags / configure scripts /
> >>  whatever
> >
> >
> > it shouldn't. special compile flags and configure are evil. make it
> aha
>
> >>- it's using old pd header files (0.37)
> >
> > its doing this because no one updated it. So this is a bad
> > argument from someone who is able to do so.
>
> as carmen has pointed out, no one should have to update it.
> imo, it is bad by design to use a local (dead) copy of a header-file
> when there is living one next door.
>
>
> anyhow, zexy is split into one file per object to go better into the
> built system (for most objects; i have no idea how to handle objects
> like [&&~] within that context)
>
> but still, out there in the wild there are some objects that form
> "natural" groups
>
>
> mfg.asdr.a
> IOhannes
>