[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/3] gnustep-make: stage 1 of cross-compile awareness

From: Ladislav Michl
Subject: Re: [PATCH 0/3] gnustep-make: stage 1 of cross-compile awareness
Date: Mon, 13 Jan 2020 08:38:46 +0100

On Sun, Jan 12, 2020 at 11:23:45PM +0100, Fred Kiefer wrote:
> Thank you for your patches. The first two are clear improvements. The third 
> one also looks good to me, but I must admit it is really hard to read through 
> in a patch mail (and I only read the part. After the merge I 
> would regenerate configure locally). As far as I can tell you mostly moved 
> things around and unified the compiler checks to always use  ${CLANG_CC}.

That's right. The point was to use AC_PROG_CC and friends as soon as possible.
While it is possible to expand it multiple times, some macros are expanded
only at first expansion, see docs:

The ${CLANG_CC} is needed as original use of ${GCC} assumed it is set to
"yes" for gcc, but it is set for GNU Compatible Compiler. I admit this
is separate problem and probably should go into separate patch.

> I am not sure whether we will need a copyright assignment for these patches. 
> The changes themselves are not that big but it might be better if you sign 
> one.

I probably cannot do more than wait until someone from FSF responds now...

> As for our side questions
> - We use the Changelog file for a quick documentation on what was changed at 
> a specific commit. This is a lot easier to scan over when doing a release and 
>  writing up the changes for the release not. It also helps me when looking 
> for a specific commit. I know that we could get almost the same information 
> from the version control system. We had plenty of discussions about that 
> topic with David Chisnall in the past. Let’s just leave it at the point that 
> GNUstep is an old fashioned project :-)

If it helps you, fair enough, I'm going to accept it.

> - We keep the configure file itself in the version control system because we 
> don’t want to require that people that use GNUstep to have autoconf installed 
> on their machines. It also has the added benefit of being able to determine 
> the version of autoconf that gets used.

I guess you can see yourself that including configure in patches makes them
less readable. And if you are going to run autoconf yourself I do see a point
having it versioned.

It also seems reasonable to assume anyone working with VCS source has
complete build environment installed. Releases are of course different
and 'make dist' or similar should take care of running autotools.


> Fred
> > Am 12.01.2020 um 19:34 schrieb Ladislav Michl <address@hidden>:
> > 
> > Hi,
> > 
> > this is just preview promised recently to bring gnustep-make closer
> > to cross-compilation. However there's work left due to GNUSTEP_MAKEFILES,
> > GNUSTEP_CONFIG, --prefix= and DESTDIR handling. Now it cannot be made work
> > without setting everything from outside (runtime vs compiletime difference
> > while cross-compiling). Now sure about reasonable solution yet.
> > 
> > Configure changes were made to keep original meaning, so it would really
> > help if somebody could explain how it is actually supposed to work.
> > 
> > Side questions:
> > - Why is Changelog maintained as versioned file? It does not explain
> >  anything usefull to the user and is insufficient for developer
> >  (it is imposible to get a clue without looking to the VCS)
> > - Why are autotool outputs checked into VCS? It just adds garbage
> >  both reading and creating patches.
> > 
> > Thank you,
> >     ladis
> > 
> > Ladislav Michl (3):
> >  Remove hack to fake OBJCXX checks
> >  Fix GNU Make detection
> >  Initial changes to make package cross-compilation aware
> > 
> > ChangeLog    |   19 +
> > configure    | 1315 ++++++++++++++++++++++++++++----------------------
> > |  316 +++++-------
> > 3 files changed, 898 insertions(+), 752 deletions(-)
> > 
> > -- 
> > 2.25.0.rc2
> > 
> > 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]