AlfC <[EMAIL PROTECTED]> writes:

>> Why do you think it's a good idea to be able to do this?
>
> For example, suppose  that you write a header file that uses
> boost_filesystem internally, from them on you will need *always* to
> compile with the option -lboost_filesystem.

Yes. So you add it to your makefile and go on with your life.

> Let's say that you give your source code that is "script-like" to
> someone else

I have no clue what a 'script-like source code' is.

> , she should know implementation details about some
> library called boost_filesystem that she never heard about and worst ,

No, she doesn't. She only needs to know that your source depends
on the Boost library, and therefore she should install 'boost-devel'
package, and use the Makefile you supplied to build your sources.

> the compilation gives awful errors messages about linking

If she doesn't have Boost installed, the compilation will give
awful errors about compiling. Should gcc be able to also:

  #install_boost_if_necessary
  #add_correct_include_flags
  #add_correct_define_flags

to 'automagically' resolve compilation problems as well?

> besides it is not standard, why do you think it is a *bad* idea to be
> able to do this?

It's a bad idea because it hides the fact that you need libboost
inside the object file. UNIX users to do not expect this command:

  gcc main.o

to 'magically' search for any library besides libc.

It's also a bad idea because UNIX linkers do not use $LIB environment
variable to find libraries. If you need libboost.so, and there are
4 different versions installed on the system, which one should the
linker pick? The one in /usr/lib may not be the right one.

It's also a bad idea because users will be confused when main.o
needs one version of libboost, but foo.o needs another (possibly
incompatible) version. I see this on windows all the time:

  link foo.obj bar.lib zork.lib /nodefaultlib:libc.lib
    /nodefaultlib:libcmt.lib /nodefaultlib:libcd.lib msvcrt.lib

Clearly, the user of this command is begging the linker to "just
please, please link that damned executable so I can go on with
my life".

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus

Reply via email to