Re: [jamboost] Re: [v2] como support

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-05-25 09:21:22

On Wednesday 25 May 2005 17:33, David Abrahams wrote:

> > Clearly, you should be able to specify
> > 1. The name of compiler binary
> > 2. The path to the compiler binary
> >
> > This together means that you should be able to specify full compiler
> > filename, like /usr/opt/llvm-g++ and have things work.
>
> Yes, that's fine for toolsets that are represented by a single primary
> executable, as most compilers are.
>
> > This leads to a simple rule: you specify the command that invokes
> > the compilerr.
>
> No, that's not fine. It leads to things like
>
> /usr/funkybin/distcc g++
>
> or
>
> /usr/bin/g++ -mmipspro
>
> which don't work, except in half-baked ways and only with particular
> toolsets. Any toolset that needs to deduce the directory where the
> compiler actually resides will choke on those constructions.

By 'command' I meant a single command -- i.e an binary name with an optional 
path. I'm not trying very hard to defend the "distcc g++" trick.

> > With msvc, the compiler name is almost always the same.
>
> As it is with most compilers.
>
> > But, for consistency sake, I decided that you still should provide
> > the command. Otherwise, you'd have to remember that for msvc and
> > borland you should provide path (without compiler name), and for
> > other toolset you must provide command (path + executable name).
>
> I understand that decision, but I think it came in part from trying
> too hard to fit all the configuration into a single argument, and in
> part from the presumption that it's very common to want to use
> compilers that are installed with nonstandard executable names. I
> know you and I do that all the time, but I don't think Joe Developer
> does.

Joe Developer probably has just a single compiler, in which case plain

using msvc ;

is likely to work.

> Another possibility would have been to ask people to provide specific
> and separate arguments for the compiler name when it is other than the
> default. Ultimately you have to give them flexibility to rename
> specific components of the toolset (e.g. the linker) independently
> anyway, so that approach would scale up in a more consistent and
> uniform manner.

Yes, we need to provide separate control over compiler/linker/whatever names.
But it's would be clumsy to write:

using gcc : 4.0 : /usr : compiler-name=g++-4.0 ;

Maybe we should figure out the interface for all other configuration options
(prefix/sufix/exact command line) first.

> > For compilers like msvc, this means that toolset essentially throws
> > away the executable name part, but I think it's better then having
> > different user interface for initialization of different compilers.
>
> Well, c'mon: we really shouldn't throw it away if we ask people to
> specify it. After all, the same arguments you give for wanting to
> customize the executable invoked for other toolsets apply here too.

Ah.. looking at the code, it's not really thrown away -- it's used as passed
by the user.

> >> > 1. In your case, V2 cannot really verify that the above command will
> >> > work, and so issues pointless (in your case) warning.
> >> >
> >> > 2. If I want to build with visual C++ under Linux (using windows
> >> > emulator), I don't want calling any setup scripts, I just want to
> >> > call a single command that I provide.
> >>
> >> An emulator shouldn't have any problems with the setup scripts.
> >> What's wrong with the setup scripts under the emulator?
> >
> > Heh? I don't think that "call" is a valid command under Unix, and that's
> > what stock action contains, verbatim.
>
> I thought you were going to run the whole action under an emulated
> command shell. That's what I'd do if I really wanted to run toolsets
> designed to work under windows.

I don't have the slighest idea if running "cmd.exe" with a command will work.

> BTW, you start an emulator up for each object file? What emulator is
> this? Is it fast? I might like to try it.

I did not try anything real with msvc, because of that 'call' issue. I do 
regularly use some other compiler, though, and the overhead to start the
compiler is not noticable. The files are small to compile time never was an 
issue. The emulator is wine (http://winehq.com). I'd recommend getting the
most recent version there is.

> >> If the toolset needs setup script configurability, it should have an
> >> option to disable setup:
> >>
> >> using msvc : 7.1 : : setup="" ;
> >>
> >> > We can handle this by using several modes of initialization:
> >> >
> >> > 1. If 'simple' mode, only compiler command is specified, toolset tries
> >> > to figure out the rest.
> >>
> >> It's not simple if it's hiding incomprehensible magic. Furthermore,
> >> it's part of the build system's job to figure out what command to
> >> invoke. I don't see how being asked to specify the command is simpler
> >> than being asked to say where the toolset is installed, for the simple
> >> case.
> >
> > Because "where installed" is not that clear itself.
>
> I think it's pretty clear. If you insist, I could rephrase and say:
> "the path to the directory where the toolset's primary executable
> resides." For toolsets like g++, msvc, etc., the primary executable
> would be the compiler.

Let me recall that in V1, there's another notion, "installation root", and I 
think that for msvc that the directory that contains "bin", "lib" and 
"include" directories. So this gives three variables -- 'install root',
'directory with the compiler, and 'full path to the compiler'.

> For compilers like g++, for which it's very common to have to specify
> a nonstandard path, specifying the directory of the executable is much
> worse than saying "where installed" , 

I'm completely lost. Above you say that "where installed" = directory where 
the executable resides. Now you say that "directory of the executable" is
much worse that "where installed". Isn't this the same? Or you talk 
specifically about *saying" and mean that one *term* is better then the 
other.

> because it's very common to 
> configure gcc-x.y.z with --prefix=/usr/local/gcc-x.y.z and install
> without making aliases in /usr/bin. When you do that, you get a
> little tree in /usr/local/gcc-x.y.z with subdirectories bin, include,
> info, lib, libexec, man, and share. In that case, your g++ is called
> /usr/local/gcc-x.y.z/bin/g++.
>
> Even if you do make an alias for gcc-x.y.z in /usr/bin, you still need
> to add /usr/local/gcc-x.y.z/lib to LD_LIBRARY_PATH when linking and
> running programs built with that compiler. If you don't install with
> --prefix= OR if you put /usr/local/gcc-x.y.z/lib in your
> LD_LIBRARY_PATH permanently you *will* break the functioning of your
> other versions of g++, and sometimes break existing programs that are
> expecting to find libstdc++.so from those other versions. That has
> been my experience, and it's consistent with the advice you'll get
> from the GCC documentation on building/installing.
>
> If it's possible to establish multiple side-by-side versions of g++ in
> the PATH (with different names, of course), but not requiring any
> special environment setup before use, I'd love to know how. I guess
> you can make /usr/bin/gcc-x.y.z a shell script that forwards its
> arguments? Is it hard to get quoting right if you do that? That's
> not done by the default gcc install procedure, BTW.

I enjoy whatever setup Debian has. I believe that incompatible versions of
libstdc++ have different 'soname's, and so can happily coexist in the same 
LD_LIBRARY_PATH.

> On the other hand, if you say "where installed" it's pretty obvious
> that it means whatever you provided for --prefix=..., and then the BB
> toolset knows where to find the lib/ directory (by default, of
> course).
>
> > On my system, all versions of gcc are in /usr/bin. Clearly, passing
> > /usr/bin won't say anything about which version I need. Passing
> > /usr/bin/g++-2.95 is absolutely clear.
>
> Yes, what's unclear is the instructions we're giving to users about
> what to pass: when you say "the command" and then also give examples
> like "distcc g++", you're headed down a road to doom :)

I agree that if there's a clean way to specify prefix to the command, then
"distcc g++" as the command should be removed.

> >> At least in the simple case, chances are that all components of
> >> the toolset are installed together. We can ask people to tell us
> >> where the executables of the toolset are installed, for example.
> >> Seems to me that
> >>
> >> c:\Program Files\Microsoft Visual Studio\vc98\bin
> >>
> >> is every bit as easy to find and understand how to specify as
> >>
> >> c:\Program Files\Microsoft Visual Studio\vc98\bin\cl.exe
> >>
> >> and it makes sense.
> >
> > Except that it does not generalize to non-Windows systems.
>
> Of course it does, as long as there's a way to specify the executable
> name separately -- which of course we'd want to support for Windows as
> well.

Ok, and this boils our argument to whether we should be specifying, for
the case of standard toolset name

using msvc : 8.0 : some_path ;

or

using msvc : 8.0 : some_path/cl ;

Right?

> >> I don't think "prefix" and "suffix" are enough. You might also need
> >> to specify the link command, for example.
> >
> > Ok, and that too.
>
> And, IMO, that should be congruent to the way the compiler command is
> specified. I'm not sure it makes sense to make the compiler
> executable "special." That makes the whole thing harder to explain,
> because other toolsets have multiple executables, too. So then people
> have to read the general explanation that you specify "the primary
> executable" and learn that for most toolsets, that's the compiler,
> instead of just dealing with the installation directory.
>
> I believe any ambiguity over what "the installation directory" means
> can be handled nicely with documentation and diagnostics. For
> example:
>
> Toolset msvc-6.0 couldn't find executable "Bin\cl" in
> the specified installation directory, "c:\Tools\MSVC". The
> default installation directory for msvc-6.0 is "c:\Program
> Files\Microsoft Visual Studio\VC98". Please specify a
> msvc-6.0 installation path that contains an executable called
> "cl" in a subdirectory called "Bin."

I suppose we can allow the user to specify either the compiler path, or 
directory where compiler is present, or "installation root" directory, 
and guess what he meant by checking for compiler's presense.

> All of that text can be generated generically for every toolset, given
> some standard rules, like:
>
> toolset.default-installation msvc-6.0 : "C:\Program
> Files\Microsoft Visual Studio\VC98" ;
>
> toolset.find-executable user-specified-install-path : Bin\cl ;
>
> >> No, because: a toolset does not correspond to one command line, and
> >> because you haven't got a system for specifying a command-line.
> >> You can only specify a command. How will you deal with all the
> >> fragments of the command that might be required at various points
> >> in the command-line? And how will you write the rule actions to
> >> expoit them?
> >
> > Well, th rules will look like this
> >
> > action .compile
> > {
> > $(PREFIX) $(COMPILE-COMMAND) $(SUFFIX)
> > }
> >
> > action .compile
> > {
> > $(PREFIX) $(LINK-COMMAND) $(SUFFIX)
> > }
> >
> > In expert mode, you'll specify values COMPILE-COMMAND and LINK-COMMAND
> > and PREFIX/SUFFIX will be left empty.
>
> Sorry, I don't get it. Normally there are options like -Ddefines and
> -Iincludes that need to be embedded in the commands somehow.

Yea, those would go after $(COMPILE-COMMAND) and before $(SUFFIX)

> > In advanced mode you will specify COMPILE-COMMAND (just compiler command,
> > like /usr/bin/g++-2.95) and specify PREFIX/SUFFIX yourself.
>
> So you specify everything in advanced mode?

No, the command to invoke the linker will be guessed from the compiler 
command.

> > In simple mode, you will specify COMPILE-COMMAND and prefix/suffix will
> > be computes automatically.
> >
> > What's wrong with that?
>
> Only what I've said earlier about the problems with telling people
> they can write "the command to invoke the compiler."

And if we say that this 'command' should be executable name with optional 
path, and no shell magic is allowed?

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2