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 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
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
> From: Paul Smith
> Cc: Eli Zaretskii , bug-make
> Date: Mon, 29 Apr 2013 19:53:26 -0400
>
> I'm not saying make_host is wrong. I do wish there was something more
> generic available (maybe in addition) that let people know "posix" vs
> "windows" vs. "vms" vs. "amiga" vs. whatever, and avoid a
> From: Paul Smith
> Cc: Tim Murphy , bug-make@gnu.org
> Date: Mon, 29 Apr 2013 16:34:01 -0400
>
> On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote:
>
> > > Yes, that should be possible. My concern is that, at least on UNIX, the
> > > rules for this are complex and I don't want to reimple
> ... or VMS shell (whatever that is) ...
it was called DCL (Digital Command Language, I suspect) and the one
feature I remember clearly is its help. If you typed "help" at the
prompt, it was actually *helpful* in response.
I have not seen that since.
Eddy.
_
On Mon, Apr 29, 2013 at 7:53 PM, Paul Smith wrote:
> Well, David, when you suggested it I wasn't so sure. But now that I've
> thought of it myself... brilliant!! :-p :-)
But now I'm having second thoughts ...
-David
___
Bug-make mailing list
Bug-make
On Mon, 2013-04-29 at 17:00 -0400, David Boyce wrote:
> On Mon, Apr 29, 2013 at 4:34 PM, Paul Smith wrote:
> > Plus on UNIX any extension is acceptable since we're using dlopen()
> > (even with the normal linker you can give any library name you want,
> > it's only the -l flag that makes assumptio
On Mon, Apr 29, 2013 at 4:34 PM, Paul Smith wrote:
> Plus on UNIX any extension is acceptable since we're using dlopen()
> (even with the normal linker you can give any library name you want,
> it's only the -l flag that makes assumptions). Maybe someone wants to
> write pattern rules to build th
13 matches
Mail list logo
