Prev: SPARK : surprising failure with implication
Next: -gnatN breakage was: Child vs nested package : efficiency matter
From: Yannick Duchêne (Hibou57) on 9 Jun 2010 10:24
Le Wed, 09 Jun 2010 13:33:47 +0200, AndreiK <andrei.krivoshei(a)gmail.com> a
écrit:
> There is sayd, that "Standard project files can import library project
> files", BUT not sayd, that "Standard project files MUST import ONLY
> library project files"
> Have somebody any advise?
>
> Best regards,
> Andrei

Hi Andrei

With due respect, your comment seems contradictory with your original
post. In your original post, Cpp_BI_SSLL_DLL, which is a library project,
attempts (and fails to) import Cpp_AdFilters, which is a standard project,
that is, an application project.

Either you wanted to import a library project from a standard project, and
then what you posted in the original post is wrong (it do the opposite),
either you wanted to import a standard project from a standard project as
you say in the present post, and then, your original post is wrong two,
because is imports a standard project from a library project.

What was your original intent please ?

Have a nice day

--
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
-- i.e. forget about previous premises which leads to conclusion
-- and start with new conclusion as premise.
From: AdaMagica on 10 Jun 2010 01:10
To summarize the GNAT project import relations:

A library project can only import library projects.
A normal (a non-library) project can import library projects and other
normal projects, i.e. any projects.

There are also abstract projects, i.e. those without sources. I guess
they can only import other abstract projects, but I haven't the
documentation at hand.
From: Andrei Krivoshei on 10 Jun 2010 08:50
> What was your original intent please?

My original intent:

The dinamic library project, say A project, (the final product)
shoould import some another project, say B project, (collection of
functions and objects- tagged records and etc).
I am myself the author of the both projects, therefore for me doesn't
matter what kind of project I select for B. But the final library
project must be compiled correctly.

Ok, if "A library project can only import library projects.", then why
I cannot import the static library project into dynamic library
project?
If I try do this, the gnatmake gives: [mlcb_fe_dll.gpr:3:09: shared
library project "mlcb_fe_dll" cannot import static library project
"sp_lib"]
Thus, if I want to build the dynamic library project, which uses
another projects, then I need to change the type of those projects to
'dynamic', and consequently, the resulting library, A.dll (for the
Windows) MUST be supplyed by whole complect of others libraries
(B.dll, C.dll, ...), which were imported into project A?

With regards,
Andrei
From: Yannick Duchêne (Hibou57) on 10 Jun 2010 09:04
Le Thu, 10 Jun 2010 14:50:17 +0200, Andrei Krivoshei
<andrei.krivoshei(a)gmail.com> a écrit:

> My original intent:
>
> The dinamic library project, say A project, (the final product)
> shoould import some another project, say B project, (collection of
> functions and objects- tagged records and etc).
> I am myself the author of the both projects, therefore for me doesn't
> matter what kind of project I select for B. But the final library
> project must be compiled correctly.
So B has to be a library... which seems OK after what follows.

> Ok, if "A library project can only import library projects.", then why
> I cannot import the static library project into dynamic library
> project?
> If I try do this, the gnatmake gives: [mlcb_fe_dll.gpr:3:09: shared
> library project "mlcb_fe_dll" cannot import static library project
> "sp_lib"]
Did you try to make all library dynamic ? Are there some reason which
disallows this ?

> Thus, if I want to build the dynamic library project, which uses
> another projects, then I need to change the type of those projects to
> 'dynamic',
So you may have a DLL depending on another DLL, which is legal on Windows.

> and consequently, the resulting library, A.dll (for the
> Windows) MUST be supplyed by whole complect of others libraries
> (B.dll, C.dll, ...), which were imported into project A?
I am not sure I have understood. If A.dll depends on B.dll and C.dll, this
should be OK. Whar kind of dependencies do you have ? Are they like the
ones I give ?

I am bit surprised, as it should be possible to build a DLL using static
library. Unfortunately, I have never experimented this with GNAT. Anyway,
feel free to give more details.

--
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
-- i.e. forget about previous premises which leads to conclusion
-- and start with new conclusion as premise.
From: Dmitry A. Kazakov on 10 Jun 2010 09:48
On Thu, 10 Jun 2010 05:50:17 -0700 (PDT), Andrei Krivoshei wrote:

> The dinamic library project, say A project, (the final product)
> shoould import some another project, say B project, (collection of
> functions and objects- tagged records and etc).
> I am myself the author of the both projects, therefore for me doesn't
> matter what kind of project I select for B. But the final library
> project must be compiled correctly.
>
> Ok, if "A library project can only import library projects.", then why
> I cannot import the static library project into dynamic library
> project?

That depends on the linker and loader capacities of the given OS. In the
worst case you have to distinguish the library build project and the
library import project. (These can be physically one gpr file, though) The
former can import anything. The latter describes a library which is already
linked and can only be loaded, but not re-linked. In this case it may not
depend on a static library.

> Thus, if I want to build the dynamic library project, which uses
> another projects, then I need to change the type of those projects to
> 'dynamic', and consequently, the resulting library, A.dll (for the
> Windows) MUST be supplyed by whole complect of others libraries
> (B.dll, C.dll, ...), which were imported into project A?

No, you can build a library as you wish. It can incorporate other projects,
i.e. became one big lump, or else refer to other projects in the form of
dynamic libraries. The choice is up to you.

When your library is to be used by in other projects you describe it
appropriately for them (using Externally_Built set to true).

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: SPARK : surprising failure with implication
Next: -gnatN breakage was: Child vs nested package : efficiency matter