Yaakov (Cygwin/X) wrote: > Dave Korn wrote: >> Here are a few mods which I found useful when building GCC-4. They're >> diff'd against the 1.5-distro version of cygport that I've been working >> with but I could port them up to SVN if they're OK; I see that cygconf() >> has moved to the autotools class file. > > Let me preface with this: Some packages won't be (in cygport terms) > "one-liners". gcc is certainly complex enough that some of the burden will > need to be carried by the .cygport(5) rather than cygport(1).
Yes, of course. I'd like to avoid cut'n'pasting large chunks of cygport(1)
into my .cygport(5) just to make minor tweaks to the functionality, but of
course I can if I have to. I'd rather not because effectively I'd be forking
the cygport(1) code that way. It seems unlikely that the cygport functions I
would override would change their semantics or interactions with other
top-level functions, but maybe some of the internal cygport private functions
they call might change in a future version, so I'd need to maintain the copied
code WRT future cygport updates.
I'm aware that defining a global (shell) variable to modify the behaviour of
cygconf is ugly; I'd be keen to implement it a better way if you have any
suggestions.
> At the same time, I'll do what I can to help. But without looking at your
> .cygport and patches to see what you're doing, I'm really a bit in the
> dark. (You can send these privately if you wish.)
The only patches I have are the ones attached to that post; the cygport file
as I currently have it is attached here for reference. (Or did you want the
src.patch?)
>> First up: how about adding "-p" to the diff options? It makes the
>> generated source patches more easily human readable.
>
> Fair enough; I'll go ahead and apply this.
Thanks :)
>> Secondly: I need to ship a patched ltmain.sh with GCC-4, so I'd like it
>> to be added to the section where automake and libtool get a smaller set
>> of default_excludes. This should be uncontroversial.
>
> Not so fast. :-) automake and libtool are exceptions here because they are
> the original sources of those packages;
Effectively, GCC is *also* an original source of this file!
> But you normally can't update ltmain.sh without an aclocal call to pick up
> the matching macros; a mixmatch of these breaks libtool. How are you
> updating ltmain.sh in a way that couldn't be automated?
GCC uses a forked libtool and ltmain.sh is not autogenerated. Hence I need
to ship it, and if I want to modify it, I have to make sure the diffs end up
in the src.patch.
>> Thirdly (and fourthly, but I don't have a patch for it yet): GCC-4 is a
>> bit of a pain. Most of the subdirectories are configured with
>> autoconf-2.59, but one uses 2.61. The directories that use 2.59
>> absolutely require 2.59, which is no longer part of the cygwin distro; I
>> haven't investigated if the one that uses 2.61 would be ok with 2.59.
>
> That's very coordinated of them. It's bad enough that you can't use a
> current version, but it's going to be a real pain if different directories
> must use different versions.
<shrugs> It is what it is. fixincludes/configure was accidentally
regenerated with the wrong version just before the 4.3 branch was cut. The
next time it was regenerated it got fixed back to 2.59 on mainline, but by
then it was too late for 4.3 branch.
>> The third patch addresses the first part of this, by allowing me to
>> reduce the set of prefix-related options passed by cygconf() to the
>> top-level configure, allowing the sub-configures to correctly default
>> whatever they respectively call the particular options. It's a bit ugly,
>> and I'm not wedded to the particular way of doing it, but it seems a
>> shame to copy and paste the whole of cygconf into my cygport script just
>> to override a couple of lines.
>
> Don't you think that's a bit much just to save two arguments to configure
> for one package?
Quite possibly so, which is why I sent the patch for discussion. Maybe I
should just reconfigure the fixincludes dir with 2.59 and then it won't
matter, but I can't do that unless I can ship the diffs to the generated
configure file. So I guess that if I can have the facility proposed in the
as-yet-hypothetical fourth patch, I wouldn't need the horrible kludge in the
third patch.
>> The fourth patch, which I haven't written yet before discussing it here,
>> would apply to __pkg_diff(), and would allow me to prevent "configure"
>> and "Makefile.in" from being added to the default_excludes list. This
>> would let me ship with patched versions of the generated files meaning
>> that users could build the whole thing without needing autotools or
>> having to worry about rolling back their autoconf using the Cygwin time
>> machine or similar. Unless you had a preferred way of doing it, I'd
>> probably just add another variable definition and test it with ifdef, as
>> in the third patch, but I'll wait to see what you have to say about all
>> these before doing any more hacking.
>
> I see your point, given the hard dep on ac-2.59, but: 1) wouldn't you need
> to not exclude more than configure and Makefile.in?
Nope, I haven't had any need to do that so far as I'm only modifying
configure.ac and Makefile.am files to any extent. None of the other excludes
have affected me (apart from the previously mentioned ltmain.sh).
> 2) can you still run just automake, avoiding the Makefile.in?
I could actually, that's not such a problem as autoconf, since the Cygwin
distro includes all the required versions.
> 3) you still need to worry about automating the autoconf run for yourself
> and other contributors.
I figure that autoconf isn't going to be necessary for most people who want
to build the package from source because they mostly won't be patching the
sources at all, and of those who do, most of them aren't likely to be patching
the configure/build system.
> If I see what you've got so far, I may be able to better figure this out.
So, I've attached my working .cygport as it is at the moment. As you can
see in src_compile(), I'm obliged to autoconf a couple of dirs and just hope
it works for the user. If I could skip this step it wouldn't matter what
version of autoconf the user had installed (unless of course they wanted to
patch configure.ac themselves). As you say, automake doesn't have this
problem, since the Cygwin distro includes all versions, it's just that
__pkg_diff(), in excluding generated files, assumes that there's going to be
an autoreconf step during the build stage, and for GCC that can't easily be
the case.
> Hope this helps,
Sure does, thanks :)
So, to sum up:
1. Are you now OK with adding GCC to the same case as automake and libtool
when setting the initial value of default_excludes?
2. What sort of approach to patching __pkg_diff() to give control over whether
or not to diff the generated files would you find acceptable?
DaveK
gcc4-4.3.2-2.cygport
Description: Binary data
------------------------------------------------------------------------------
_______________________________________________ Cygwin-ports-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
