Changeset e7d893b for introduction/important/building-notes.xml
- Timestamp:
- 05/19/2019 04:54:33 AM (5 years ago)
- Branches:
- elogind
- Children:
- 215c728b
- Parents:
- 853ae3e5
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
introduction/important/building-notes.xml
r853ae3e5 re7d893b 454 454 </sect2> 455 455 --> 456 <sect2 id="buildsystems"> 457 <title>Working with different build systems</title> 458 459 <para> 460 There are now three different build systems in common use for 461 converting C or C++ source code into compiled programs or 462 libraries and their details (particularly, finding out about available 463 options and their default values) differ. It may be easiest to understand 464 the issues caused by some choices (typically slow execution or 465 unexpected use of, or omission of, optimizatons) by starting with 466 the CFLAGS and CXXFLAGS environment variables. 467 </para> 468 469 <para> 470 Most LFS and BLFS builders are probably aware of the basics of CFLAGS 471 and CXXFLAGS for altering how a program is compiled. Typically, some 472 form of optimization is used by upstream developers (-O2 or -O3), 473 sometimes with the creation of debug symbols (-g), as defaults. 474 </para> 475 476 <para> 477 If there are contradictory flags (e.g. multiple different -O values), 478 the <emphasis>last</emphasis> value will be used. Sometimes this means 479 that flags specified in environment variables will be picked up before 480 values hardcoded in the Makefile, and therefore ignored. For example, 481 where a user specifies '-O2' and that is followed by '-O3' the build will 482 use '-O3'. 483 </para> 484 485 <para> 486 There are various other things which can be passed in CFLAGS or 487 CXXFLAGS, such as forcing compilation for a specific microarchitecture 488 (e.g. -march=amdfam10, -march=native) or specifying a specific standard 489 for C or C++ (-std=c++17 for example). But one thing which has now come 490 to light is that programmers might include debug assertions in their 491 code, expecting them to be disabled in releases by using -DNDEBUG. 492 Specifically, if <xref linkend="mesa"/> is built with these assertions 493 enabled, some activities such as loading levels of games can take 494 extremely long times, even on high-class video cards. 495 </para> 496 497 <bridgehead renderas="sect3" id="autotools-info">Autotools with Make</bridgehead> 498 499 <para> 500 This combination is often described as 'CMMI' (configure, make, make 501 install) and is used here to also cover the few packages which have a 502 configure script that is not generated by autotools. 503 </para> 504 505 <para> 506 Sometimes running <command>./configure --help</command> will produce 507 useful options about switches which might be used. At other times, 508 after looking at the output from configure you may need to look 509 at the details of the script to find out what it was actually searching 510 for. 511 </para> 512 513 <para> 514 Many configure scripts will pick up any CFLAGS or CXXFLAGS from the 515 environment, but CMMI packages vary about how these will be mixed with 516 any flags which would otherwise be used (<emphasis>variously</emphasis>: 517 ignored, used to replace the programmer's suggestion, used before the 518 programmer's suggestion, or used after the programmer's suggestion). 519 </para> 520 521 <para> 522 In most CMMI packages, running 'make' will list each command and run 523 it, interspersed with any warnings. But some packages try to be 'silent' 524 and only show which file they are compiling or linking instead of showing 525 the command line. If you need to inspect the command, either because of 526 an error, or just to see what options and flags are being used, adding 527 'V=1' to the make invocation may help. 528 </para> 529 530 <bridgehead renderas="sect3" id="cmake-info">CMake</bridgehead> 531 532 <para> 533 CMake works in a very different way, and it has two backends which can 534 be used on BLFS: 'make' and 'ninja'. The default backend is make, but 535 ninja can be faster on large packages with multiple processors. To 536 use ninja, specify '-G Ninja' in the cmake command. 537 </para> 538 539 <para> 540 The hardest part of using CMake is knowing what options you might wish 541 to specify. The only way to get a list of what the package knows about 542 is to run <command>cmake -LAH</command> and look at the output for that 543 default configuration. 544 </para> 545 546 <para> 547 Perhaps the most-important thing about CMake is that it has a variety 548 of CMAKE_BUILD_TYPE values, and these affect the flags. The default 549 is that this is not set and no flags are generated. Any CFLAGS or 550 CXXFLAGS in the environment will be used. If the programmer has coded 551 any debug assertions, those will be enabled unless -DNDEBUG is used. 552 The following CMAKE_BUILD_TYPE values will generate the flags shown, 553 and these will come <emphasis>after</emphasis> any flags in the 554 environment and therefore take precedence. 555 </para> 556 557 <itemizedlist> 558 <listitem> 559 <para>Debug : '-g'</para> 560 </listitem> 561 <listitem> 562 <para>Release : '-O3 -DNDEBUG'</para> 563 </listitem> 564 <listitem> 565 <para>RelWithDebInfo : '-O2 -g -DNDEBUG'</para> 566 </listitem> 567 <listitem> 568 <para>MinSizeRel : '-Os -DNDEBUG'</para> 569 </listitem> 570 </itemizedlist> 571 572 <para> 573 CMake tries to produce quiet builds. To see the details of the commands 574 which are being run, use 'make VERBOSE=1' or 'ninja -v'. 575 </para> 576 577 <bridgehead renderas="sect3" id="meson-info">Meson</bridgehead> 578 579 <para> 580 Meson has some similarities to CMake, but many differences. To get 581 details of the defines that you may wish to change you can look at 582 <filename>meson_options.txt</filename> which is usually in the 583 top-level directory. 584 </para> 585 586 <para> 587 If you have already configured the package by running 588 <command>meson</command> and now wish to change one or more settings, 589 you can either remove the build directory, recreate it, and use the 590 altered options, or within the build directory run <command>meson 591 configure</command>, e.g. to set an option: 592 </para> 593 594 <screen><userinput>meson configure -D<some_option>=true</userinput></screen> 595 596 <para> 597 If you do that, the file <filename>meson-private/cmd_line.txt</filename> 598 will show the <emphasis>last</emphasis> commands which were used. 599 </para> 600 601 <para> 602 Meson provides the following buildtype values, and the flags they enable 603 come <emphasis>after</emphasis> any flags supplied in the environment and 604 therefore take precedence. 605 </para> 606 607 <itemizedlist> 608 <listitem> 609 <para>plain : no added flags. This is for distributors to supply their 610 own CLFAGS, CXXFLAGS and LDFLAGS. There is no obvious reason to use 611 this in BLFS.</para> 612 </listitem> 613 <listitem> 614 <para>debug : '-g'</para> 615 </listitem> 616 <listitem> 617 <para>debugoptimized : '-O2 -g' - this is the default if nothing is 618 specified, it leaves assertions enabled.</para> 619 </listitem> 620 <listitem> 621 <para>release : '-O3 -DNDEBUG'</para> 622 </listitem> 623 </itemizedlist> 624 625 <para> 626 Although the 'release' buildtype is described as enabling -DNDEBUG, and all 627 CMake Release builds pass that, it has so far only been observed (in 628 verbose builds) for <xref linkend="mesa"/>. That suggests that it might 629 only be used when there are debug assertions present. 630 </para> 631 632 <para> 633 The -DNDEBUG flag can also be provided by passing 634 <command>-Db_ndebug=true</command>. 635 </para> 636 637 <para> 638 To see the details of the commands which are being run in a package using 639 meson, use 'ninja -v'. 640 </para> 641 642 </sect2> 643 456 644 </sect1>
Note:
See TracChangeset
for help on using the changeset viewer.