avoid all dependencies on libraries (that have been specified with
LinkSharedOSLibs or a rule that uses it).
This means you can now run a
NO_LIBRARY_DEPENDENCIES=1 jam MyApp
to build MyApp without updating any library MyApp depends on, even if they
have changed. This is a feature for people who know what they are doing to
speed up development.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13483 a95241bf-73f2-0310-859d-f6bbb57e9c96
StaticLibraryFromObjects is a copy-paste of LibraryFromObjects without grist on source files
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13199 a95241bf-73f2-0310-859d-f6bbb57e9c96
StaticLibrary now accepts static libraries to include (note that jam should be rebuilt)
LibraryFromObjects doesn't FGristFiles now, but Library does
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13119 a95241bf-73f2-0310-859d-f6bbb57e9c96
- removed libnetapi.so from $NETWORK_LIBS - it's not used by anyone anyway,
and it's definitely not necessary to link against it by default.
Note, this might cause problems in some of the mail add-ons; I haven't
tested this.
- route/ping/... now also link against $SELECT_UNAME_ETC_LIB
makehdimage should now work again under all BeOS platforms.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12325 a95241bf-73f2-0310-859d-f6bbb57e9c96
for building under Linux.
* Tried to get the header setup into a shape that would allow us to build
under Linux with gcc 3.x. But I give up for the moment. The C++ support
headers don't seem to be separate from the STL headers, which makes it
virtually impossible to use our STL together with gcc 3.x.
Worse, I don't even think, how we build under BeOS at the moment is
correct. The _G_config.h (glibc configuration) header is included from
some public headers, but is itself not made available. This causes the
R5 header to be used, which belongs to a completely different glibc
version. But when building our libroot we use the new header. I wouldn't
be surprised, if that could cause all kinds of subtle problems. Maybe
even the STL string problem I encountered recently.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11607 a95241bf-73f2-0310-859d-f6bbb57e9c96
flags to be used. Defaults to -g. You might want to use -ggdb with
gcc 3.x.
* Added variable C++_SUPPORT_LIBS. Is set to sup++ for gcc 3.x.
* ResComp can be built under BeOS only at the moment.
* Define _NO_INLINE_ASM when building for the build platform. Is not
strictly necessary under BeOS, but helps under Linux.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11561 a95241bf-73f2-0310-859d-f6bbb57e9c96
not just .o - newer GCC releases seem to have .oS objects in libgcc.a).
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11057 a95241bf-73f2-0310-859d-f6bbb57e9c96
That makes fine tuning any of them a nicer experience.
You have to rerun ./configure in order to build anything.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11056 a95241bf-73f2-0310-859d-f6bbb57e9c96
DEBUG_PRINTF to be defined.
* Fixed KernelAddon rule: Now not the file but the target kernel.so is
specified for linking the add-on against, which results in proper
dependencies. Axel: Want to clarify the ToDo comment?
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10754 a95241bf-73f2-0310-859d-f6bbb57e9c96
HDRSEARCH won't be set on the sources which may cause header dependencies
to be missing.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10010 a95241bf-73f2-0310-859d-f6bbb57e9c96
issues, they deprecated that nice function. This will enable it again.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@7937 a95241bf-73f2-0310-859d-f6bbb57e9c96
