2
0
mirror of https://github.com/boostorg/build.git synced 2026-02-14 00:32:11 +00:00
Commit Graph

8 Commits

Author SHA1 Message Date
Vladimir Prus
4d9d7d2ab6 Testsuite fixes for windows.
[SVN r55332]
2009-08-01 10:31:05 +00:00
Vladimir Prus
5930635366 Attempt at fixing generators_test on windows
[SVN r55198]
2009-07-27 07:20:34 +00:00
Rene Rivera
5b5b339cf1 Add copyrights+license (with help of a shell script).
[SVN r35861]
2006-11-06 01:44:13 +00:00
Vladimir Prus
5a44f04da8 Refactor generators a bit.
* If a generator was given a source it could not handle, it used to return
  that source together with generated targets. This was nice for some use
  cases, but no very nice for others, and this behaviour could not be turned
  off. One use case where it worked bad was:

      lib plugin : plugin.cpp helper ;
      lib helper : helper.cpp ;

  On windows, 'plugin' would link to the 'import library' and pass the DLL
  target though. So, when installing 'plugin', we'd also install 'helper.dll',
  and it was not possible to do anything about it.

* If we asked generators.construct to produce sources of type CPP,
  and the selected generator produced both targets of type CPP, and of
  some other type, we'd try again to convert those other targets to CPP.
  This simply complicated the logic for no good reason.

* Most generator function had 'multiple' parameter, which function
  was long forgotten by anybody.

As a bit of history, I believe some of the above decisions were due to a
certain use case:

          CPP <------- WHL
                          \
                            WD
                          /
          CPP <------- DLP

Here, a source file is converted to two targets with one command, and each
produced file is converted to CPP. Our generators search would notice that
there are two generators for CPP: the WHL->CPP and DPL->CPP
generators. Neither is better that the other so both are tried, and produce
(CPP, DPL) and (CPP, WHL) pairs of targets. To avoid reporting an ambiguity,
we'd try to convert, DLP to CPP and WHL to CPP, do it successfully, notice
that produced targets are the same and decide that there's no ambiguity.

However, this is rather complex logic for a relatively rare case. It can
be handled by writing another WD->CPP generator that would handle
disambiguation itself.

This commit has one user-visible change. The code:

  exe a : a.cpp b ;
  obj b : b.cpp helper;
  lib helper ;

No longer works -- the 'a' target won't link to 'helper'. However, this is
pretty stange code and worked before almost by accident.


[SVN r29361]
2005-06-02 06:43:56 +00:00
Vladimir Prus
a8758e0f2c Bugfix: allow a generator to create two targets of the same type.
* new/generators.jam
  (generator.__init__): Use parallel lists to store prefixes and postfixes
  for a name, not mapping with type as a key, since type is not unique.
  (generator.generated-targets): Adjust.


[SVN r19990]
2003-09-10 07:39:45 +00:00
Vladimir Prus
b6d69f0b88 Revive all the tests.
* boost_build_v2.html: Document new option.

* new/generators.jam (find-viable-generators): Revert part of Dave's
   commit, essentially disabling finding base type generators.
   This part breaks a test, and need to be thinked about.

* new/errors.jam: Handle "--no-error-backtrace" option.

* test/project_test4.py: Adjust for new error syntax.


[SVN r16233]
2002-11-14 10:17:50 +00:00
Vladimir Prus
609dd1f6ab Introduced SHARED-LIB and STATIC-LIB target types. Also introduced LIB target
type and a generator, which relays either to SHARED-LIB or STATIC-LIB,
depending of the value of "shared" feature.


[SVN r15529]
2002-09-27 07:35:03 +00:00
Vladimir Prus
4a7a508bc2 Added future generators test -- not automated now.
[SVN r14926]
2002-08-16 14:25:22 +00:00