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
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
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
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
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 tnmur...@gmail.com wrote:
I'm
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
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, the
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 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
On Tue, Apr 30, 2013 at 3:57 AM, Tim Murphy tnmur...@gmail.com 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
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
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
it
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:
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
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 order
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 recursive
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
* 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 stefano.lattar...@gmail.com
---
ChangeLog| 8
configure.ac |
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:
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.
*
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'
Date: Tue, 30 Apr 2013 08:57:23 +0100
From: Tim Murphy tnmur...@gmail.com
Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org 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.
On 30 April 2013 17:28, Eli Zaretskii e...@gnu.org 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
Date: Tue, 30 Apr 2013 17:48:42 +0100
From: Tim Murphy tnmur...@gmail.com
Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org 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
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 point
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
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
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
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
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
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
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
32 matches
Mail list logo
