跨平台编译实践：C++构建MacOSX、Linux与Windows应用

需积分: 10 23 浏览量更新于2024-07-26 收藏 3.28MB PDF 举报

"交叉编译平台是开发人员在不同操作系统上构建软件的一种技术，它允许在一台设备（宿主机）上编译代码，然后在另一台设备（目标机）上运行。这种技术常用于嵌入式系统开发，因为开发环境通常比目标环境资源丰富。在C++中进行跨平台开发，需要考虑兼容性、库和工具链等多个因素。" 交叉编译平台的核心是交叉编译器，它与传统的本机编译器不同，后者是在同一硬件平台上编译和运行代码。交叉编译器则使用一个特定的工具链，这个工具链包括编译器、链接器、汇编器等，它们针对目标系统的架构进行优化。例如，一个在Linux环境下运行的交叉编译器可以用来创建适用于Windows或嵌入式设备（如ARM架构的设备）的应用程序。在进行交叉编译时，开发者需要注意以下关键问题： 1. **目标架构**：明确知道你要编译的代码将运行在什么类型的处理器和操作系统上。不同的架构可能需要不同的编译选项和库支持。 2. **工具链配置**：正确配置交叉编译工具链是至关重要的。这包括设置`CC`、`CXX`等环境变量，指向正确的交叉编译器，以及确保链接器和其他工具知道如何处理目标系统的依赖。 3. **头文件和库**：确保你有适用于目标系统的头文件和库。在跨平台开发中，可能需要使用特定于平台的API或库，这些需要在编译时正确引用。 4. **平台差异**：理解并处理不同操作系统之间的差异，如文件系统、路径表示、线程模型等。C++标准库在不同平台上的实现可能会有所不同，因此需要使用条件编译指令来处理这些差异。 5. **构建系统**：使用像CMake、Autoconf或Meson这样的跨平台构建系统可以帮助简化配置过程，并确保代码在多个平台上能正确构建。 6. **测试**：在目标平台上进行充分的测试，以验证应用程序的功能和性能。这可能需要建立一个自动化测试框架，以便在多种环境中运行测试。 7. **移植性**：编写可移植的代码是跨平台开发的关键。避免依赖特定平台的特性，尽量使用标准库和跨平台的第三方库，如Boost或Qt。 8. **版本控制**：使用版本控制系统（如Git）来管理源代码，便于在不同平台之间同步和协同开发。 9. **许可证和法律问题**：在跨平台开发中，确保遵循所有使用的库和工具的许可证条款。这可能会影响你如何分发和修改代码。 10. **文档**：良好的文档可以帮助团队成员理解和维护跨平台项目。包括平台特定的构建指南、配置说明以及代码中的注释。通过以上要点，开发者可以在C++中成功实现跨平台开发，创建能够在MacOSX、Linux和Windows等多平台运行的应用程序。同时，了解和适应各平台的特性和限制，将有助于创建更加健壮和可扩展的软件。

During the ten or so years of my career prior to joining Netscape in 1998, I

had the good fortune to work on a wide variety of projects, on an equally

diverse set of platforms. I worked on an embedded kernel of my own design

for a somewhat obscure CPU (the TMS34020). I obtained experience in

Windows kernel development, writing ﬁle systems drivers for the Windows

NT and Windows 98 kernels, to support the development of a Network File

System (NFS) client. In user space, I mostly specialized in user interface

development, initially developing Motif (Z-Mail) and OpenWindows

applications for UNIX, eventually getting exposure to Win32 and the

Microsoft Foundation Classes (MFC) toolkit on the Windows platform. I

even had the chance to write code for the Classic Mac OS to support a

project that would be shipped by Apple, using the Mac Toolbox application

programming interface (API). All of this code was written in the C language,

and all of it was highly nonportable, written only with a concern for the job,

and platform, at hand.

But then I joined Netscape, as a UNIX expert of sorts. Initially, I was

assigned the task of working on bugs in the 4.x Netscape browser, speciﬁcally

handling defects ﬁled against a port of the browser to IBM’s Advanced

Interactive eXecutive (AIX) platform. Netscape had a contract with IBM to

ensure that bugs ﬁled against the AIX version of the Netscape browser, or

bugs that IBM considered important, were ﬁxed in a timely fashion, and this

contract funded my hiring. Similar deals were cut with SGI, Hewlett-Packard,

and Sun, and perhaps others, and these deals funded additional Netscape

staff. Two or three of us were assigned to deal with AIX, speciﬁcally.

During this time, portability had not yet been perfected at Netscape.

Although much of the codebase of Netscape was portable, the project did

not have a uniﬁed build system, and the user interface code was completely

Preface

platform speciﬁc. Many bugs had a decidedly platform-speciﬁc nature to

them (hence the need to have separate teams to support individual plat-

forms). Code that worked ﬂawlessly on the Windows version of Netscape

ran horribly on less well-supported platforms. Not all platforms had the

same set of features, and features varied from platform to platform.

Within a year of joining Netscape and ﬁxing AIX bugs, I somehow

earned my way onto the Netscape Instant Messenger team, and worked on

the new codebase based on the open source Mozilla platform. This team,

which consisted of three engineers, was tasked with porting the AOL Instant

Messenger client to the Netscape browser. The Netscape IM team was

hastily formed right after AOL acquired Netscape, to try to bring AOL-

based functionality into the application. (The other major AOL property

integrated into Netscape was support for AOL Mail.)

The new Netscape client, in development at that time, was, as men-

tioned previously, based on the open source codebase named Mozilla. This

codebase, at the time, was largely the product of Netscape engineers located

in ofﬁces located in San Diego, and Mountain View, but contributions from

the open source community were on the rise. (I refer to the project as

Netscape/Mozilla in the remainder of this Preface.)

Netscape was in ﬁerce competition with Microsoft for the browser

market at this time, which meant the browser of course had to work well,

and ship on time on the Windows platform. Netscape also generated

signiﬁcant advertising revenue through the Netscape portal, and clicks there

were highest when a new version of the browser was released, and tens of

millions of users visited the portal to download a fresh copy of Netscape.

Supporting Netscape not only on Windows but also on Mac OS and Linux

helped keep the number of visits high and generate revenue. So, Linux and

Mac OS were treated as equals with Windows within the Netscape culture,

not only because it was the morally right thing to do (as many of us

believed), but also because every visit to the Netscape portal was important

to the bottom line of the company.

Netscape/Mozilla was a complete departure from anything that I had

ever seen or worked on before. First of all, this new version of Netscape was

not just a browser, it was a platform, capable of hosting applications. (The

primary examples shipped with Netscape were AIM, the Mail/News client,

a WYSIWYG HTML editor named Composer, the Chatzilla IRC client, and

the browser itself. Extensions, such as those available for Firefox today, are

closely related.) Instead of building the graphical user interface (GUI) for

these applications in C or C++, using APIs provided by a native platform

xvi Preface

GUI toolkit such as MFC or Gtk+, Netscape/Mozilla-developed technolo-

gies were used instead. Static Extensible Markup Language (XML) ﬁles

were used to describe the layout of the user interface, much like HTML is

used to describe the layout of a Web page. The XML dialect developed for

this purpose was called XML User Interface Language (XUL). JavaScript

code, linked to the XML elements via attributes much like JavaScript is

linked to HTML elements in a Web page, was used to respond to menu item

selections and button clicks. To build an application for Netscape/Mozilla,

all one needed was this combination of XML and JavaScript; and because

both JavaScript and XML are intrinsically portable, so were the user

interfaces that were designed using these technologies. When JavaScript

wasn’t enough to do the job (as was the case for any real applications, like

those shipped with Netscape and Mozilla), JavaScript code could call C++

functions that provided the guts of the application, housed in shared

libraries. These shared libraries, or components, were directly supported in

the Netscape/Mozilla architecture via two technologies: XPConnect and

XPCOM. These technologies allowed component developers to deﬁne

platform-agnostic interfaces using an Interface Description Language (IDL).

Using XPCOM and XPConnect, JavaScript code could query for the

existence of a component, and from there, query for a speciﬁc interface. If

all was good, the JavaScript code was handed an object that it could call just

like any other object, except the object was written in C++, and was capable

of doing things that JavaScript programmers could only dream of. The

interfaces, by their nature, were highly platform agnostic.

The impact of the work done to support portability in the

Netscape/Mozilla architecture was not, quite frankly, immediately apparent

to me. But, over time, I came to appreciate the power of such an approach.

The positive effects of the decisions of those who came up with the

architecture are indisputable; during its heyday, Netscape was shipping tens

of millions of browsers to users, not just for Windows, Mac, and Linux, but

for SunOS, AIX, HP-UX, SGI Irix, and a host of other UNIX-based

platforms. The “tier-1” platforms (Mac OS, Linux, and Windows) literally

shipped at the same time. Each of these ports had, for the most part, the

same feature set, and mostly shared the same set of bugs and quirks. To

achieve portability at such a grand scale required a very special architecture,

and it is one of the goals of this book to give you a good understanding (if

not an appreciation) for how the Netscape/Mozilla architecture directly

impacted the portability of the codebase.

Preface xvii

However, it was not just the architecture of Netscape/Mozilla that made

the browser and related applications (AIM, Mail, Composer) portable. To

pull this sort of thing off, one needs not only a solid architecture, but also a

culture of policies and procedures that put cross-platform development high

on their lists of priorities—as well as large doses of discipline to ensure these

best practices were followed. Tools, such as Tinderbox and Bugzilla, both of

which are described in this book, were invested in heavily by Netscape and

Mozilla, and the investment paid off in spades. Engineers were forced to

consider other platforms, not just their own, and a regression found during

daily testing on just one platform could halt development on all platforms,

not just the one affected, because Netscape and Mozilla realized that the

only true way to achieve portability was to deal with the issues in the here

and now. A good chunk of this book steps away from the code, and

describes these best practices, because no matter how good your architec-

ture is in supporting cross-platform, you have to work all the platforms you

plan to support with the level of care and devotion to detail if they are going

to make it to the ﬁnish line with the same levels of quality.

Similar to the way that the programs we write are made up of data

structures and algorithms, portability, in my opinion, consists largely of

architecture and process, and this conviction is at the foundation of the

book that you now hold in your hands.

How This Book Is Organized

This book is organized as a series of themed chapters. Most of these

chapters consist of a set of items, with each item covering a speciﬁc topic

supporting the chapter’s overall theme. Early in the book, you will ﬁnd

sections that contain items presenting best practices that must be communi-

cated to the entire development organization, including management,

development, and testing. Later chapters cover software-engineering topics

that management should be aware of, but these chapters have been written

primarily for readers who will be implementing the code. In all, there are

23 items presented in these initial chapters.

The implementation of a user interface is a major concern in the

development of cross-platform desktop applications. Item 23 serves to

introduce the topic. The ﬁnal two chapters of the book are therefore

devoted to cross-platform GUI-related topics. The ﬁrst of these chapters

xviii Preface

provides a comprehensive introduction and tutorial to the wxWidgets cross-

platform GUI toolkit. After reading my introduction to wxWidgets, you

may want to check out Prentice Hall’s detailed treatment on the subject,

Cross-Platform GUI Programming with wxWidgets, by Julian Smart, et al.

wxWidgets is not the only cross-platform GUI toolkit available for use in

your projects. Another capable, and very popular cross-platform GUI

toolkit, Qt, is not covered in this book. However, if you are interested in Qt,

a few books are currently available that cover the subject in great detail,

perhaps most notably C++ GUI Programming with Qt 4, by Jasmin

Blanchette and Mark Summerﬁeld, also published by Prentice Hall (see also

their Qt 3-speciﬁc book).

The last chapter of this book, Chapter 9, “Developing a Cross-Platform

GUI Toolkit in C++,” starts with an introduction to the cross-platform GUI

toolkit, XPToolkit, which is a major component of Netscape and Mozilla’s

cross-platform browser suite. It then goes on to detail the implementation of

a toolkit I created especially for this book, Trixul. Trixul has many of the

same attributes that made up the Netscape/Mozilla XPToolkit we used at

Netscape to construct cross-platform GUIs. Both XPToolkit and Trixul, for

example, allow you to describe the user interface of an application in XML

and JavaScript, both support a component-based model that allows the user

interface to call into shared libraries written in C or C++, and both are

highly portable. However, there are two major differences between Trixul

and the Mozilla offering. First, Trixul is a desktop GUI toolkit, whereas

XPToolkit applications execute within the context of a Web browser only.

Second, the overall design of Trixul is (I think) much simpler than

XPToolkit, which (I am certain) allowed me to do a much better job of

describing both the architecture of the toolkit, and the concepts behind its

design, than I otherwise would have been able to do. Although I don’t really

expect that you will want to design a custom cross-platform GUI toolkit for

your project, there is much to be learned from taking a look at how Trixul

was designed and implemented.

The chapters, for the most part, have been written such that they can be

read in any order. If you are in technical management, I recommend that

you read the following chapters carefully:

■ Chapter 1, “Policy and Management”

■ Chapter 2, “Build System/Toolchain”

■ Chapter 3, “Software Conﬁguration Management”

Preface xix

剩余574页未读，继续阅读

tuwj2001

粉丝: 0
资源: 1

跨平台编译实践：C++构建MacOSX、Linux与Windows应用

基于minigui与海思的视频播放器总结.docx

海思平台下 minigui-配置文件.rar

oss_sdk已交叉编译arm-linux平台

Linux交叉编译平台实验.zip

构造Linux的交叉编译平台.pdf

为arm处理器建立gcc交叉编译平台

GCC构建交叉编译平台详解

周立功uCLinux交叉编译平台搭建教程

利用GCC源码构建交叉编译平台指南

在FC下架设arm交叉编译平台

最新资源