| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: I2bc45e4ba63f5faaee7389bcd9d7b3f563503186
|
|
- stop copying the DLL to OUTDIR
- since that was the main reason for the separation between
CliLibrary and CliLibraryTarget, merge the targets;
the newly inherited variables are not expected to cause problems
- hardcode target to URE bin dir for now, no immediate need for
multiple layers
Change-Id: If0fea1337349c41f231c8cde122852c71d5080a7
|
|
Introduce SDKDIRNAME as a configury variable and use it instead of the
gbuild gb_Package_SDKDIRNAME. Then we can easily construct the
SDKDIRNAME_FOR_BUILD variant that is needed to find the specially
named SDK in instdir on OS X when cross-compiling.
Move the version number section in configure.ac earlier.
Change-Id: Iee3db1a50ad4c7a9f91bbc5e0d0b01d76a76f701
|
|
The library is already in the URE/bin directory, but that is not
sufficient to be able to run sdk/bin/climaker.exe.
There are apparently 4 ways for a .net/CLR executable to locate
shared libraries:
1) in the same directory as the executable
2) in some mysterious "GAC" thing in C:/Windows
(which is presumably how it works if you actually install LO)
3) via an application configuration file entry "probing",
which only works when it's in a sub-directory of the
one the executable is in
4) via a DEVPATH variable, but that only works with a
special configuration entry in a system "machine config" file
of the .net framework
Specifically PATH is apparently ignored. Since building on Windows is
enough of a PITA already and we don't want developers to have to edit
another config file, put another copy of the library into sdk/bin.
http://tutorials.csharp-online.net/.NET_CLR_Components%E2%80%94Resolving_Names_to_Locations
http://tutorials.csharp-online.net/.NET_CLR_Components%E2%80%94CLR_Loader
Change-Id: I511957ad9a9a918ed0c316126304a1980fb2d289
|
