Re: individual software releases for third parties

[matthew sporleder <msporleder%gmail.com@localhost>]

On Sat, Sep 1, 2012 at 5:18 PM, Alistair Crooks <agc%pkgsrc.org@localhost> 
wrote:
> On Thu, Aug 30, 2012 at 11:52:35AM -0400, James K. Lowden wrote:
>> On Thu, 30 Aug 2012 14:20:41 +0100
>> Patrick Welche <prlw1%cam.ac.uk@localhost> wrote:
>>
>> > On Sat, Aug 25, 2012 at 06:53:21PM +0300, Aleksey Cheusov wrote:
>> > > One more example of how NetBSD tools may become portable without
>> > > autotools.
>> >
>> > I don't see the point of avoiding autotools - {cross,} compiling on
>> > a variety of architectures is precisely what it is designed to do.
>>
>> Eh? Autoconf determines compile-time choices by probing the build
>> host.  How is that a design for cross-compilation?
>>
>> The right way to approach portability has never been tried: to
>> construct a database of alternatives, keyed approximately by os, libc,
>> and compiler version. That list is orders of magnitude smaller than the
>> number of build hosts, and that approach has the property of aiding our
>> understanding instead of obscuring the problem.
>
> I think this is a good, albeit simplistic way of looking at things.
> It does imply a static view of system software and characteristics.
>
> It doesn't, however, address additional software which may or may not
> be on a machine, and certainly doesn't address situations where
> ncurses may be installed on a build host, but I wish to
> (cross-)compile and (cross-)link with a different curses library.
>
> It also assumes that installed software does not change over time.
> And that functions are available with the same API/ABI across the same
> major version of libs (i.e.  it doesn't take openssl into account).
> And that system characteristics are only dependent on system software.
>
> In fact, the whole discussion is reminiscent of the calls to have a
> central autoconf cache when building to speed things up (which fails
> for the same reasons given above).
>
> Regards,
> Alistair

A few years ago I was able to make netbsd's awk into an auto-tools build
with ~zero knowledge of either.

Adding new auto-tools based packages to pkgsrc is trivial to do.
This is also true for rpm, which has %setup, %configure, etc.

Another example is jmcneill's http://pkgsrc.se/wip/libinotify wihch I was
able to get into pkgsrc within minutes of it being auto-tooled.

Google's gyp, which generates makefiles based on platform defines,
but I wouldn't recommend trying to customize it.
(if you happen to do so, let me know how to make it use shlock on netbsd)

Matt