Re: Cleanup of makefiles 'n stuff

2012-01-17 Thread Edward Welbourne 
>> The contents of these files don't seem so different to me that they
>> couldn't be consolidated, perhaps with some command-line overrides
>> or similar.  Or, maybe some of them are just not needed; do we
>> really have to be able to build with nmake and smake?
>
> How about moving them to a subdirectory, where they could bit-rot out
> of sight?

In the presence of a version control system, even one as basic as CVS,
deletion isn't fundamentally worse than leaving them to bit-rot out of
site - they can always be recovered from the version-control system -
and has the virtue of not cluttering up the source tree with things that
aren't adequately supported.

>> What I was thinking was this: write a very simple, very generic and
>> portable makefile that can build make.  It wouldn't have lots of fancy
>> targets like the current SMakefile/NMakefile have, for creating
>> distributions etc.  Just the compile and link.
>
> That would be good, yes.
>
> Another thing that is probably needed is a script to run the test
> suite.  One of the first things you might want to do after building
> Make on a new platform or system configuration is to see whether the
> build passes the test suite.

Once you've built GNU make itself, *all* other operations are best
encoded in your generic portable makefile, IMO.  Of course, Paul might
want to exercise some restraint on just how many things go into it, but
the mere fact of insisting everything in it be portable and generic
should suffice to limit creature feep.  I would suppose testing to be
one of the more natural things to include in such a make file - rather
than as a separate script.  After all, if you're testing make, doing so
via a make-file is itself part of testing it works !

Eddy.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Cleanup of makefiles 'n stuff

2012-01-17 Thread Eli Zaretskii 
> From: Edward Welbourne 
> Cc: psm...@gnu.org, make-...@gnu.org, bug-make@gnu.org
> Date: Tue, 17 Jan 2012 17:08:02 +0100
> 
> > How about moving them to a subdirectory, where they could bit-rot out
> > of sight?
> 
> In the presence of a version control system, even one as basic as CVS,
> deletion isn't fundamentally worse than leaving them to bit-rot out of
> site - they can always be recovered from the version-control system

Not for people who only get the release tarballs.  And users of
platforms supported by those files typically aren't tracking the
development repo, and typically aren't fluent enough with VCSes to
know how to recover deleted files.

> and has the virtue of not cluttering up the source tree with things that
> aren't adequately supported.

They are supported, Paul just wants to find ways to lower the burden.

> Once you've built GNU make itself, *all* other operations are best
> encoded in your generic portable makefile, IMO.  Of course, Paul might
> want to exercise some restraint on just how many things go into it, but
> the mere fact of insisting everything in it be portable and generic
> should suffice to limit creature feep.

That's fine with me, provided that it's possible from a portable
Makefile.  If that is hard, having a separate script is good enough,
IMO.

> I would suppose testing to be one of the more natural things to
> include in such a make file - rather than as a separate script.
> After all, if you're testing make, doing so via a make-file is
> itself part of testing it works !

Yes, but if that fails, running just the tests, perhaps one by one,
might be a desirable feature.  For starters, it makes debugging
easier.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Cleanup of makefiles 'n stuff

2012-01-17 Thread Edward Welbourne 
>> In the presence of a version control system, even one as basic as CVS,
>> deletion isn't fundamentally worse than leaving them to bit-rot out of
>> [sight] - they can always be recovered from the version-control system
>
> Not for people who only get the release tarballs.

Good point - didn't think of that.

>> and has the virtue of not cluttering up the source tree with things that
>> aren't adequately supported.
>
> They are supported, Paul just wants to find ways to lower the burden.

In that case, they're not bit-rotting, so should no more be moved out of
sight than deleted.  But if we get to the point where we have no-one to
maintain them or no-one who can test them (a prerequisite of full
support) before releases, I can see the sense of moving them into a
subdirectory - whose ReadMe.txt can say "we haven't tested these but we
try to keep them up to date and one of them might work for your
platform, or at least be a good start-point; if you need to fix it up,
please send us a patch."

Eddy.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Cleanup of makefiles 'n stuff

2012-01-17 Thread Sebastian Pipping 
On 01/17/2012 06:28 AM, Eli Zaretskii wrote:
>> For sure once I actually take the plunge and move to a "real" source
>> code control system [...]
> 
> May I suggest bzr?  It is a GNU project and is used by Emacs, wget,
> and a few others on Savannah.

Git please.  It's fast, used by important GNU projects [1] and a ton of
others, and I sure don't want to miss Git's staging/index mechanism.

I can help with the conversion, if you want help with it.

Best,



Sebastian


[1] http://git.savannah.gnu.org/cgit/coreutils.git

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Cleanup of makefiles 'n stuff

2012-01-17 Thread Stefano Lattarini 
On 01/17/2012 09:04 PM, Sebastian Pipping wrote:
>
> Git please.  It's fast, used by important GNU projects [1] ... [SNIP]
> 
> [1] http://git.savannah.gnu.org/cgit/coreutils.git
>
And FTR also:

  http://git.savannah.gnu.org/cgit/libtool.git
  http://git.savannah.gnu.org/cgit/autoconf.git
  http://git.savannah.gnu.org/cgit/automake.git
  http://git.savannah.gnu.org/cgit/gnulib.git
  http://git.savannah.gnu.org/cgit/grep.git
  http://git.savannah.gnu.org/cgit/sed.git
  http://git.savannah.gnu.org/cgit/gawk.git
  http://git.savannah.gnu.org/cgit/m4.git
  http://git.savannah.gnu.org/cgit/tar.git
  http://git.savannah.gnu.org/cgit/diffutils.git
  http://git.savannah.gnu.org/cgit/findutils.git
  http://git.savannah.gnu.org/cgit/bison.git

(and probably some other more).  And GCC has an *official* Git mirror
as well:

  git://gcc.gnu.org/git/gcc.git

(but its main repo is still in SVN if I'm not mistaken)

Regards,
  Stefano

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #35323] When the environment is modified with export or undefine, $(shell ...) still inherits the original environment

2012-01-17 Thread Brian Vandenberg 
URL:
  

 Summary: When the environment is modified with export or
undefine, $(shell ...) still inherits the original environment
 Project: make
Submitted by: phantal
Submitted on: Tue 17 Jan 2012 09:00:02 PM GMT
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.82
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

Example:


undefine LD_LIBRARY_PATH
$(warning $(shell echo "From $$(shell ...): $$LD_LIBRARY_PATH"))

all:
  @echo "From $@: $$LD_LIBRARY_PATH"



The $(warning ) will print the original LD_LIBRARY_PATH.

As you might expect, variations on this theme are no different; all of the
following have identical results:

export undefine LD_LIBRARY_PATH

undefine LD_LIBRARY_PATH
export LD_LIBRARY_PATH

undefine LD_LIBRARY_PATH
export LD_LIBRARY_PATH:=




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make