> I've been working for porting GNU/Linux to Hitachi SuperH processor.
> (Please visit http://www.m17n.org/linux-sh/ for the project.)
> SuperH is the CPU for embedded target, PDA, and video game machine.
> Our target tuple would be:
> SH-VENDER-LINUX-GNU
[...]
> Currently, there's the br
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> SOME_TEST()=> --with-somethingsome test [default=yes]
Lars> SOME_TEST( , , nodefault ) => --with-somethingsome test [default=no]
Lars> I've tried some stuff but without any luck... What seems to be one of
Lars>
Ian Lance Taylor wrote:
> Don't do that. *-pc-* is only used for IBM PC compatible systems. On
> non-Intel targets, the configuration name for GNU/Linux is
> CPU-unknown-linux-gnu.
OK, I see. I'll do with "unknown". Thanks all for the clarification.
--
Niibe Yutaka
Wow, sounds like there is plenty of exciting things to check here. I
have access to some Solarises, I will try with them to see if I can
get all the data I need. Thanks a lot for the report (and don't lose
these guys :).
Akim
In message <[EMAIL PROTECTED]>, Alexandre Oliva writes:
>On Feb 13, 2000, Ossama Othman <[EMAIL PROTECTED]> wrote:
>
>> I like this idea. The AC_PROG_CXX macro would then be something like
>> the following (based on AC_PROG_CXX in the CVS repo):
>
>> AC_PROG_CXX([LIST-OF-COMPILERS],
>>
In message <[EMAIL PROTECTED]>, Akim Demaille writes:
>
> Wow, sounds like there is plenty of exciting things to check here. I
> have access to some Solarises, I will try with them to see if I can
> get all the data I need. Thanks a lot for the report (and don't lose
> these guys :).
>
> Akim
I've defined a macro (AC_DEFUN) with this "prototype":
SOME_TEST([ ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND [, ATTRIBUTE-LIST ]]])
In ATTRIBUTE-LIST, I can specify things like "nodefault" or "default" and
whichever features I want to add later.
Inside SOME_TEST I use the AC_ARG_WITH(something,
Olly> What exactly do you have in mind here? Are you thinking of a macro to
Olly> specify a level or perhaps better a list of requirements, maybe along
Olly> the lines of:
Olly> AC_SET_CXX_REQUIREMENTS(templates libstdc++)
Olly> AC_PROG_CXX
Olly> Or something where the user actually passes in
Configure options change. I'd like to issue an error message to the user
if they happen to use an old option (or point them to the new one). The
problem is that AC_ARG_WITH automatically adds all options to the help
output, which is sort of against the point of deprecating options. Any
clues?
--
Hello!
I understand that every "good" developer should have help2man on every
machine (and thus I'm a bad guy :-)), but anyway...
configure.in uses AM_MISSING_PROG with 2 arguments
m4/missing.m4 expects 3 arguments and has no default for the 3rd argument.
The result is an idiotic message about
On Feb 16, 2000, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Configure options change. I'd like to issue an error message to the user
> if they happen to use an old option (or point them to the new one).
if test "x${with_option_name+set}" = xset; then
AC_MSG_ERROR([option-name is deprecated,
The "Makefile.in" file distributed with autoconf appears to be incorrect.
There are two problems, one of which I've hit and the other of which I
don't intend to try:
The "install" target, when it installs the scripts, does not install them
from the source directory. Thus, if you are using GNU
Assar Westerlund wrote:
>Ben Pfaff <[EMAIL PROTECTED]> writes:
>> Either I'm very confused, or it's not possible to use the autoconf
>> tests AC_EXEEXT and AC_MINIX in the same configure.in...
>
>Yes, this is a problem. But in this particular case I would say that
>AC_MINIX should be considered o
13 matches
Mail list logo
