Add examples showing how to use cflags.SH to tweak the compiler flags used for individual object files. Previously cflags.SH contained a somewhat stale pre-canned list of file basenames including removed files such as usersub (deleted before 5.000 shipped), and a partial list of 5.000 XS extensions. Whilst it's possible to generate the correct list in cflags by parsing MANIFEST (and adding a few fixups), it's still not actually *useful*, as cflags gets overwritten as soon as config.sh changes. Hence the most end-user useful solution with minimal maintenance is to eliminate the list entirely, and document how the user should add to it as necessary.
All these files used to be executable in the release tarballs. Apparently things also work without that in the repository, but I'd rather add this possibly unecessary change to blead instead of breaking the upcoming release. This should probably be looked into again afterwards.
The perl source has for some while been clean to -Wwrite-strings. I suggest this warning be added to cflags. The patch makes the appropriate change to cflags.SH and silences a warning from mg.c
When porting/makerel runs, all files copied into the directory for the tarball have the executable bit stripped and then only a specific set of files have the executable bit restored. There are many files in the repo that have the executable bit set in the repo that will be stripped. So that the state of files in the repo is as close as possible to the state of files in the release tarball, the executable bit has been stripped from such files. In one recent case, a file added from a dual-life module needed the executable bit set. Because it had the bit in the repo but was not listed in makerel to get an executable bit, tests using it passed in the repo and failed in the tarball. This commit refactors the list into a new file, Porting/exec-bit.txt and add tests to detect a mismatch between files listed there and actual executable bits in the repo.
…process Rename the old "unpushed.h" to "git_version.h" and make it hold the defines that used to come from cflags magic
… process The net result of this patch is to make available via Config.pm and -v/-V the details about the git version info we have available for the build. When built within a git repository git is queried directly. When built from a snapshot or bundle it is assumed that the source is unchanged, and that the required details are avaialble in a file called .patch, whose format current is a four field string in the following format: "$branchname $date.$time $sha1 $describe". The generator of these files currently resides on camel.booking.com. * git-describe is now used more directly with -v. When the prefix of git-describe matches the version number as determined by the defines in patchlevel.h then we use ONLY the git-describe output, otherwise we include the git describe in parenthesis after the version number. Either way the describe text is optionally followed by a star should there be uncommitted changes. eg: This is perl, v5.11.0 (GitLive-blead-136-g58ca560) built for i686-linux or: This is perl, v5.11.0-1-g58ca560 built for i686-linux or: This is perl, v5.11.0 built for i686-linux * include the SHA1 in perl -V summary, and automatically include unpushed commits in the registered patches list * include various git/version/.patch details in %Config, as follows: git_commit_id # sha1 of HEAD git_ancestor # ancestor in $remote/$branch (presumably canonical) git_describe # git describe git_branch # current branch git_uncommitted_changes # "true" if there are any, empty otherwise git_unpushed_commits # List of sha1's of unpushed commits git_commit_id_title # Used to make the perl -V summary output Additionally one more value is added depending on build process used: when building from an rsynced snapshot (or any dist including a file called .patch) then the second field will be used to populate the "git_snapshot_date" field. Otherwise if built in a git directory (as is hopefully recommended these day) then the field will be "git_commit_date" which will be the commit date of HEAD. This patch introduces two new files (on top of .patchnum) that will be generated by make_patchnum.sh: "lib/Config_git.pl" and "unpushed.h", the former is used to make git data available to Config.pm/%Config without rebuilding everything else, and the second is used to expose unpushed commits (if any) via the registered patch facility of patchlevel.h
…lace so it only affects perl.c
…ated whenever cflags.SH changes
Change elsif to the correct "else if" construction. I suspect that this slipped by into f6a8029 because cflags.SH doesn't seem to be re-expanded if it's newer than cflags.
This is just an initial attempt at getting something more useful into the -v / -V output. Currently "patchlevel" is really "version", and PATCHNUM is just a special string added to the patchlevel in perl.c via defines created by cflags.SH and its product file cflags, which happens very early in the build process. This means that for committers the -v output is likely to not be upto date unless they run make clean. Anyway, IMO we should rethink a reasonable amount about how we do this, this is just a crude step forward.
and regexp reference counting is via the regular SV reference counting. This was not as easy at it looks. p4raw-id: //depot/perl@32804
gcc link flags so that any implementation dependant libraries are also linked in. p4raw-id: //depot/perl@32669
…lags when possible. p4raw-id: //depot/perl@32647
From: "Robin Barker" <Robin.Barker@npl.co.uk> Message-ID: <46A0F33545E63740BC7563DE59CA9C6D09398B@exchsvr2.npl.ad.local> p4raw-id: //depot/perl@32623
…ac OS X Message-ID: <Pine.LNX.firstname.lastname@example.org> Date: Tue, 23 Oct 2007 08:54:51 -0400 (EDT) p4raw-id: //depot/perl@32181
Message-ID: <Pine.LNX.email@example.com> Date: Mon, 22 Oct 2007 12:49:25 -0400 (EDT) p4raw-id: //depot/perl@32174
Message-Id: <46C15106.firstname.lastname@example.org> p4raw-id: //depot/perl@31710
Message-Id: <200703300144.l2U1iBSA490663@kosh.hut.fi> p4raw-id: //depot/perl@30779
command-line options, but this C file was including perl.h, which in turn includes config.h, which might not be present at that time. So force the generation of config.h. p4raw-id: //depot/perl@30019
assume we really want it p4raw-id: //depot/perl@30016
Message-Id: <253514EB-BA57-4A43-93FA-75D6F3CF27BC@mac.com> p4raw-id: //depot/perl@29398
Message-ID: <email@example.com> p4raw-id: //depot/perl@28955
Message-ID: <4520E41E.firstname.lastname@example.org> p4raw-id: //depot/perl@28914
Message-ID: <450F8BEA.email@example.com> p4raw-id: //depot/perl@28867
Message-ID: <45083D88.firstname.lastname@example.org> Plus a tweak to the name of CC. p4raw-id: //depot/perl@28842