Re: CVS commit: pkgsrc/lang/gcc9

[Roland Illig <roland.illig%gmx.de@localhost>]

My plan is to watch the bulk builds for a few more iterations to collect more platforms and to see which files they actually install.

I don't like it that a quite critical package as a compiler can just "install every file it wants" and be regarded as successfully installed.

Since I was the first to package GCC 9, nine months after its initial release, I thought that it would not matter much if it would take a few more days until this package becomes practically usable 
and stable.

My goal is to understand under which circumstances each of the files is installed, and to document this, in the form of the PLIST files. At the end of my experiment I will probably be happy to 
generate the list of include files automatically, but I don't want to do that for bin/ and share/locale, just to name a few. I also found it interesting that on Darwin, gcc installs both libtool 
libraries and dylib libraries at the same time, which I hadn't expected before.

Therefore I'd like to continue this experiment for a few days. Before 2020Q1 is branched I will definitely convert it into a more stable form.

Roland

Am January 10, 2020 9:24:29 AM UTC schrieb Jonathan Perkin <jperkin%joyent.com@localhost>:
>* On 2020-01-10 at 00:28 GMT, Roland Illig wrote:
>
>> Module Name: pkgsrc
>> Committed By:        rillig
>> Date:                Fri Jan 10 00:28:03 UTC 2020
>> 
>> Modified Files:
>>      pkgsrc/lang/gcc9: PLIST
>> Added Files:
>>      pkgsrc/lang/gcc9: PLIST.Darwin-x86_64 PLIST.NetBSD-x86_64
>> 
>> Log Message:
>> lang/gcc9: split PLIST into platform-specific files
>> 
>> The PLISTs differ a lot between the platforms. For gathering the
>initial
>> data it is easier to just list the files per platform than trying to
>get
>> all the conditions right in the first place.
>> 
>> There will be conditions for operating systems, for platforms, for
>> features, for version-specific include files to be fixed, for
>installed
>> programming languages, for nls, and several more.
>
>This is why we use dynamic plists for GCC.  Yes, it's not ideal, but
>it's far preferable to this alternative where the package is broken on
>the vast vast majority of pkgsrc platforms.
>
>I don't like this at all.