On Wed, 2013-05-01 at 00:59 +0200, Stefano Lattarini wrote:
># With make 3.82, compiled from official tarball:
>$ make -f- <<<'all:; @echo $(MFLAGS)' -I none
>-I none
>
># With development version of make:
>$ make -f- <<<'all:; @echo $(MFLAGS)' -I none
>-Inone
I think MFLA
On Tue, 2013-04-30 at 17:20 -0700, Jim Michaels wrote:
> I wasn't digressing. I was explaining the point. the concept I am
> trying to present as a solution to the problem of making parallel
> stdin for --jobs in gnu make (which currenty doesn't work and is I
> guess single-threaded) is to make a
you only have to read the documentation to know that it doesn't support
parallel stdin.
you would know that if you had followed the thread. here's the documention,
read around the middle.
http://www.gnu.org/software/make/manual/html_node/Parallel.html
>
>
Jim Michaels wrote:
what if you in your makefile are creating files from scratch using echo, based
on system configuration information?
I know I have to do that in order to create XML manifest files for resources
to compile and link in via resource compiler for windows builds.
echo writes to st
what if you in your makefile are creating files from scratch using echo, based
on system configuration information?
I know I have to do that in order to create XML manifest files for resources to
compile and link in via resource compiler for windows builds.
I can give you a sample of some of the
Jim Michaels wrote:
I wasn't digressing. I was explaining the point. the concept I am trying to
present as a solution to the problem of making parallel stdin for --jobs in
gnu make (which currenty doesn't work and is I guess single-threaded) is to
make a separate terminal or command shell for
I wasn't digressing. I was explaining the point. the concept I am trying to
present as a solution to the problem of making parallel stdin for --jobs in gnu
make (which currenty doesn't work and is I guess single-threaded) is to make a
separate terminal or command shell for each job, such as v
Few automake-generated recipes have the necessity to determine at
runtime whether a particular make mode/option is active (e.g., '-k'
or '-n'). To do so, they analyze the content of the $(MFLAGS) make
variable.
But the exact format of this variable has been changed in the
development version of G
I ran all of the load and loadapi tests in the test suite and found a
couple of problems in the current implementation that were based on
unportable assumptions. The solutions touch to some extent the
platform independent code and build requirements, so I'd like to
discuss them here before I actua
That stuff about only using gnu tools is far from the case.
Re this usecase supporting multiple platforms. The reason why it
doesn't help is that all the rest of your makefile has similar
multiplatform problems which you have to address with ifeq and its
friends and it is nastier if you have make
On Tue, 2013-04-30 at 17:48 +0100, Tim Murphy wrote:
> i.e. I don't just have
> load X.dll
> I have to supply the recipe to build it on windows:
> X.dll:
> cl.exe /Fdo$@ # use microsoft's compiler
> and on Linux
>
> X.so:
>gcc -o $@ ... # using gcc
Actually this supports Eli's p
> Date: Tue, 30 Apr 2013 17:48:42 +0100
> From: Tim Murphy
> Cc: "Paul D. Smith" , "bug-make@gnu.org"
>
> > That's unrelated. I was talking about the fact that
> >
> > load foo.so
> >
> > is inherently non-portable, whereas
> >
> > load foo
> > or
> > load foo$(SOEXT)
> >
> >
On 30 April 2013 17:28, Eli Zaretskii wrote:
>
> > Since you can't (in my recent experience) load a 64-bit DLL into a 32-bit
> > program, the real issue is what architecture was make itself built with.
>
> That's unrelated. I was talking about the fact that
>
> load foo.so
>
> is inherentl
> Date: Tue, 30 Apr 2013 08:57:23 +0100
> From: Tim Murphy
> Cc: "Paul D. Smith" , "bug-make@gnu.org"
>
> Since you can't (in my recent experience) load a 64-bit DLL into a 32-bit
> program, the real issue is what architecture was make itself built with.
That's unrelated. I was talking about t
On 04/30/2013 05:11 PM, Stefano Lattarini wrote:
> * configure.ac (AM_INIT_AUTOMAKE): Here. The future major Automake
> version 2.0 (ETA about one, one and half year from now) will likely
> enable them by default, so better prepare ourselves.
>
Please drop this patch. Enabling 'subdir-objects' w
GNU make already assume C89 or later throughout the codebase, and
that preprocessor conditional was no longer used anyway.
* configure.ac: Remove AC_DEFINE of HAVE_ANSI_COMPILER.
* config.ami.template: Remove #define of HAVE_ANSI_COMPILER.
* config.h-vms.template: Likewise.
* config.h.W32.template
The second patch requires the first (as silent rules were only
introduced in automake 1.11). The third patch should be fully
independent.
Stefano Lattarini (3):
build: require Autoconf >= 2.62 and Automake >= 1.11.1
build: enable 'subdir-objects' and 'silent-rules' automake options
build: g
* configure.ac (AM_INIT_AUTOMAKE): Here. The future major Automake
version 2.0 (ETA about one, one and half year from now) will likely
enable them by default, so better prepare ourselves.
Signed-off-by: Stefano Lattarini
---
ChangeLog| 8
configure.ac | 2 +-
2 files changed, 9 ins
Older versions of those tools should be considered fully obsolete.
Also, GNU make already requires Gettext >= 0.18.1, which has been
released six months after Automake 1.11.1 and two years after
Autoconf 2.62; so the new requirement shouldn't be problematic
for people already bootstrapping GNU make
On Tue, 2013-04-30 at 16:04 +0200, Stefano Lattarini wrote:
> On 04/30/2013 03:37 PM, Paul Smith wrote:
> > Just to be clear, you're saying that the testsuite runs as one long
> > operation, updating one target, and the recipe invokes one test script,
> > right?
> >
> No; the testsuite runs as a re
Hi Paul.
On 04/30/2013 03:37 PM, Paul Smith wrote:
> Just to be clear, you're saying that the testsuite runs as one long
> operation, updating one target, and the recipe invokes one test script,
> right?
>
No; the testsuite runs as a recursive make invocation (yes, this is sadly
truly needed in or
Just to be clear, you're saying that the testsuite runs as one long
operation, updating one target, and the recipe invokes one test script,
right? I can see how that environment might be problematic for this new
feature. It works much better for lots of smaller targets.
However, you could avoid
Most of these were found using Lucas De Marchi's 'codespell' tool.
* ChangeLog: Fix minor typos.
* ChangeLog.2: Likewise.
* README.Amiga: Likewise.
* TODO.private: Likewise.
* function.c: Likewise.
* glob/glob.h: Likewise.
* job.c: Likewise.
* main.c: Likewise.
* readme.vms: Likewise.
* remake.c:
On 04/30/2013 03:06 PM, Paul Smith wrote:
> On Tue, 2013-04-30 at 11:19 +0200, Stefano Lattarini wrote:
>> The above has been obtained with GNU make built from latest
>> git version (commit 'moved-to-git-46-g19a69ba').
>
> Yes. I know the email lately has been daunting but if you wade through
> i
On Tue, 2013-04-30 at 11:19 +0200, Stefano Lattarini wrote:
> The above has been obtained with GNU make built from latest
> git version (commit 'moved-to-git-46-g19a69ba').
Yes. I know the email lately has been daunting but if you wade through
it you'll see a number of emails discussing this issu
On Tue, Apr 30, 2013 at 3:57 AM, Tim Murphy wrote:
> Since you can't (in my recent experience) load a 64-bit DLL into a 32-bit
> program, the real issue is what architecture was make itself built with.
> It's sort of a matter of make identifying itself rather than telling you
> that you're running
On 04/30/2013 01:22 PM, Tim Murphy wrote:
> I know this isn't going to go down all that well, but I really think the
> output should be annotated in such a way that colourisation could be
> applied to the log file after a build has already finished.
>
While this might (underline "might" ;-) be an i
I know this isn't going to go down all that well, but I really think the
output should be annotated in such a way that colourisation could be
applied to the log file after a build has already finished.
e..g you load a makefile into VIM - it can colourise it. Or a bit of C
source code. Why not the
On 04/30/2013 12:01 PM, Tim Murphy wrote:
> What I mean is that:
>
> ./make -Otarget
>
> might be a good interactive default rather than -Omake.
>
I wasn't even aware of those differences; as of latest Git commit
'moved-to-git-46-g19a69ba', I don't see them documented in either
the help screen, t
On 04/30/2013 11:55 AM, Tim Murphy wrote:
> I'm guessing here but I imagine the main problem comes with delaying the
> results of submakes?
>
I think so, yes. The Distributed Make from Sun implements a similar
output synchronization feature, and doesn't have the output delay problems
I have experi
What I mean is that:
./make -Otarget
might be a good interactive default rather than -Omake.
Colouring is another issue which I would imagine could be done another way
to let us have the best of both worlds.
Regards,
Tim
On 30 April 2013 10:55, Tim Murphy wrote:
> I'm guessing here but I i
I'm guessing here but I imagine the main problem comes with delaying the
results of submakes?
I haven't tested to see if this is how the new feature works or not. I
don't think it's completely necessary to keep all output from one submake
together. so turning that off might make things more intera
I'm sorry to say that the new -O option can interact *badly*
with Automake-generated parallel testsuites (at least when they
are being run "interactively", that is, with the output of make
connected to a tty).
Let me elaborate a little (if you still have doubts or objections
after reading the cons
Here is a minimal reproducer:
$ cd /tmp
$ mkdir x
$ cd x
$ mkdir src
$ echo 'all:; $(MAKE) -C src $@' > Makefile
$ echo 'all:; @echo src' > src/Makefile
$ make # Work es expected
make -C src all
make[1]: Entering directory '/tmp/x/src'
src
make[1]: Leaving directory '/tmp/x/s
Since you can't (in my recent experience) load a 64-bit DLL into a 32-bit
program, the real issue is what architecture was make itself built with.
It's sort of a matter of make identifying itself rather than telling you
that you're running on ubuntu 13.04 or solaris 10.
Regards,
Tim
On 30 April
35 matches
Mail list logo
