[PD] compiling pluginhost~ on Ubuntu/Mint

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-10-10 22:24, Hans-Christoph Steiner wrote:
> 
> On Oct 10, 2012, at 1:18 PM, Jamie Bullock wrote:
> 
>> 
>> Anyhow, to conform to the policies and conventions of the Pd svn,
>> I've removed the headers and added the requisite instructions to
>> the README as suggested.


while i agree with hans that those 3rd party headers would better not
be in svn, there is really no policy enforcing that.

> So if you really want, I'm ok with you putting the headers that
> were in include/ directly into pluginhost~.  Then you won't need
> the -Iinclude.

opinions here differ: if you really want to add those 3rd party
headers to the SVN, then *I'd* suggest to leave them in a separate
directory, in order to keep your sources and 3rd party sources apart.


> My issue is about putting those external headers in the 'make dist'
> tarball.  This setup would allow people to build using those
> headers if they checked out via SVN, but if they download the
> source tarball from the release, they'd need to get those headers
> from an 'official' source.  That official source could also be
> downloading the source tarballs and copying them into place.
> 

hmm, but this seems even weirder to me.
people who are using svn checkouts, are most likely up for some extra
exercises.
they already installed subversion, why would it bother them to install
some random dev-package?
otoh, people who are using the dist tarball, cannot even be expected
to run autoconf.

(expectation is always very subjective, so i don't expect people to
have the same expectations when downloading from svn or tarballs, it's
still true though, that in my experience building from a repository is
usually a bit less convenient than building from a release tarball)



anyhow:
the pd-extended way for handling 3rd-party libraries in svn seems to
add the full 3rd party library sources into [1], so on the Pd-extended
build machines you can expect those libraries to be present.

another possibility would be provide the headers (even in dist), but
make the use of those headers optional, to the extend that the default
is not to use those headers (and instead use the system-installed or
fail) and people have to take active steps to enable those headers,
following detailed instructions in README.txt


tgamsdr
IOhannes


[1] http://pure-data.svn.sourceforge.net/viewvc/pure-data/sources/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlB2b/IACgkQkX2Xpv6ydvSuKACeI6YiJSe6TmJzwuOjhwnmsNAM
jkYAoMs1/SIxjwCNHAMWKP6A4l95wwyU
=NqSJ
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2320 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20121011/912afa6f/attachment.bin>