U++ forum: Welcome to the forum

Re: Understanding packages, assemblies, and nests [message #44472 is a reply to message #44471]

Sun, 15 March 2015 08:15

mirek
Messages: 13976
Registered: November 2005

Ultimate Member

Quote:

I do not understand why non-main packages do not have build flags. Don't non-main packages have to be built also ? Suppose I create a shared library use the IDE. I assume a shared library is another package, just like anything else being built in the IDE from source files. Don't I need build flags to tell the IDE how to build the shared library ?

This is not the purpose of build flags. They are usually used as 'binary-wide' settings. Some of them are recognized by build system (e.g. MT says that application is multithreaded, which affects the way how packages are compiled, GUI says that it is gui application, which is recognized by Win32 builders etc...), some are application specific, e.g. developer can decide to recognize 'DEMO' build flag, which would restrict the functionality of resulting executable. Your main package can have multiple main configurations.

Quote:

Regarding have the IDE add a package which already exists as a .upp file: are you saying that this package needs to go in an already existing assembly ? Or can I create a new assembly for the package ? Are assemblies just a grouping mechanism for packages in the IDE so that a user of the IDE can open the package by finding it within a particular assembly ?

Yes. It is like include path or say system 'PATH' (for finding executables).

Quote:

Can a package be in more than one assembly, ie. can different assemblies have the same nest in its list of nests ?

Definitely!

More importantly, you can use assemblies to e.g. select version of library. Say you have 'stable' libraries and 'experimental' - you can have two assemblies, one will group your main project with experimental, other with stable library.

Quote:

I also see that one can choose a non-main package to be opened in the IDE, but the menu item says 'File | Set main package...'. Isn't this a misnomer since the end-user can choose a non-main package to build ?

True. Practical needs sometimes blur things... perhaps it would be more correct to have 'main package' and 'package with main configuration' as two distinct terms, but later is too long...

Quote:

You wrote "Usually, your package would by in MyApps, and it would depend on for example on Core, which is located in the uppsrc nest." Does this mean that packages which the end-user creates should go into the MyApps assembly ? I am gathering that the other assemblies are for Ultimate++'s own use, except maybe for MyAppsWBazaar.

It is something like initial suggested setup. E.g. when I start theide on my work laptop, I have about 40 assemblies in the list Smile

Quote:

3) A main package is never a dependent of any other package.

Actually, there is no such limitation. Main package in fact can be used in another main package dependency. There is even a macro 'flagMAIN' that is only defined when package is build as main.

Usage scenario: Imagine I would want to create text editor which would provide much of functionality that 'theide' provides, but I would be too lazy to correctly split ide main package sources into correct 'non-main' package. I could have all sources of theide included into new main package by simply adding theide into now project and perhaps putting some of #ifdefs flagMAIN into it. It is not typical, perhaps not even recommended, but sometimes ends justify means...

(rest of your points is correct).

Mirek

Report message to a moderator