AlfC wrote: > On Sep 17, 5:51 pm, Paul Pluzhnikov <[EMAIL PROTECTED]> > wrote: >> 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. > > and then I have to mantain a makefile. ok, one gets used to this. > >>> 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. > > yes you do: a small code with few docen of lines, that does a simple > task, like renaming files, inspects them, do this and that . >> >> If she doesn't have Boost installed, the compilation will give >> awful errors about compiling. > > at least it will tell what files are missing. > >> 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? > > yes, and make a cup of coffee, > no, I am talking about some simple task that involves gcc only, after > all I what looking for something that suggest gcc what to look for, > something that can be easily switched off or overwritten. >> >>> 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. >> > so, after all gcc writers accepted that libc should be linked by > default, basically I am asking for something that by default links to > certain libraries. > >> 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. > > I understand, but that is why if implemented it should be as some > suggestion to the compiler that can be ignored if let say there are > more than one version of the file. > Following the example, what if there is more than one version of libc? > g++ won't cry, will it? > >> 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. > > beginners are confused anyway. > >> 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 >> > I didn't think about that, good point. > It seems that Windows can do it (see response from Pedro) with its > problems, gcc just can't. > ok, I just wanted to make sure I wasn't missing something with gcc. > Boost people apparently would smile if something like this is > implemented (see Pedro's link), at least it will simplify their > Getting Started page. > Don't get me wrong I still will use g++. > > Thank you very much for your answer, this autolinking may be wasn't a > great idea after all. pkg-config largely solves these problem, and runs with more compilers than just gcc - all you have to do is write mylib.pc that gets passed around with your library, and knows that your library depends upon boost/kitchen_sink etc.
Alan _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
