Re: [eclipse-clp-users] compact eclipse platform

2009/12/30 Kish Shen <kisshen_at_...5...>

>  luke2k4_at_...6... wrote:
>
>> Hi All,
>> I am writing to ask if there is a convenient way to compile a set of
>> eclipse
>> libraries into one assembly that could be loaded at start-up of the
>> eclipse
>> engine ?
>> I would like the platform to be as compact as possible containing only the
>> necessary libraries compiled in one libs_all.eco file which would be
>> loaded
>> at eclipse start-up..
>>
>> I've tried the following approach:
>> I've loaded the solver and therefore all necessary libraries got loaded.
>> Than used a short eclipse script to:
>>
>>   1. get a list of all compiled files
>>   2. filter out those that belong to the solver ( leaving only the library
>>
>>   files belonging to the platform )
>>   3. concatenate the files to one lib_all.ecl
>>   4. compile lib_all.ecl to lib_all.eco
>>
>>
>> than use the lib_all when starting eclipse.exe with -b option , or better
>> to
>> include the assembly when running the eclipse via the c interface.
>> I am running into some problems during point 4.
>>
>> I would be grateful if someone could let me know if there is an easy way
>> to
>> prepare such a compact eclipse platform.
>>
>>  Hi Luke,
>
> It is not very clear from what you wrote what exactly you are after. For
> example, do you want to distribute an ECLiPSe that is as small as possible
> (to run your application), or if you want the ECLiPSe to occupy as small a
> memory footprint as possible when you run it?
>
> If you want to reduce the file sizes of the programs you need, then using
> eco format may not be the best, because it is not a very compact
> representation, and the size of an eco file can be larger than the original
> ECLiPSe source file.
>
> The compiled ECLiPSe code in the eco format is portable, in that you can
> compile it on one platform and load it on another platform, even between
> platforms with different word lengths (as long as you avoid things like
> integers that might be too big in the platform with smaller word length).
> There are various issues that prevents the raw binary form of the abstract
> machine code stored in a runtime ECLiPSe to be directly portable. Aside from
> the obvious ones like word length and absolute addresses, some are more
> subtle, such as the location of an attribute in an attributed variable
> depends on the order in which the modules defining the attribute are loaded.
>
> Putting everything into a single eco file will also not compact the total
> size of the file you need significantly, because the size of the resulting
> ecofile (in number of bytes) will be the same as the sum of all the
> individual eco files.
>
> There are also some tricky issues with having a single eco file at the
> moment, and ECLiPSe does not provide a way to do this currently.
>
> You can reduce the size of the ECLiPSe distribution, as well as its memory
> footprint, by using the runtime ECLiPSe package (available as the eclipse_rt
> tarball) as a starting point. This ECLiPSe does not have a toplevel nor
> debugging facilities, as the ECLiPSe files for these functionalities (they
> are written in ECLiPSe itself) are not included.
> Of course, this is only suitable for running ECLiPSe applications, and not
> for development of your programs.
>
> The runtime package currently includes most of the libraries in addition to
> the kernel, but you can throw these out if you are not using them.
>
> The runtime package will reduce the size of ECLiPSe code you need to
> include with your system, but it does not change the low-level ECLiPSe size
> (the part of ECLiPSe written in C). To reduce this, you will need to compile
> ECLiPSe on your own. One obvious thing you can do is to compile ECLiPSe
> without bignum support (i.e. support for integers of unlimited size). bignum
> support is provided by thr GNU GMP library, so if you do not need bignums
> and rationals (which require bignums), you can use an ECLiPSe without GMP.
> This will reduce the size of the binary file, as well as the memory
> footprint.
>
> Sorry for being so long, and I hope it is of some help!
>
> Cheers,
>
> Kish
>
> --
> This e-mail may contain confidential and privileged material for the
> sole use of the intended recipient. Any review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive for the recipient), please contact
> the sender by reply e-mail and delete all copies of this message.
> Cisco Systems Limited (Company Number: 02558939), is registered in
> England and Wales with its registered office at 1 Callaghan Square,
> Cardiff, South Glamorgan CF10 5BT.
>

Hi Kish,
thank you for the extensive response. At the end of the day al the things
which you have mentioned are important when one wants to have as compact a
platform as possible (and preferably also portable) to ship as an embedded
component of some application. You have mentioned:

   1. The total size of the libraries
   2. The memory requirements of the platform (memory footprint )
   3. low-level ECLiPSe size

I've not yet gone so far to optimize in all three aspects, but i possibly
will so thank you for the suggestions.
There was an objection to embedding an eclipse based solver in an
application because of the number of files in the platform.
So my first goal was fairly simple: to reduce the total count of files. I've
cut out all that was unnecessary and being left with the key libraries
(those for eclipse engine and those additional for the solver) i wanted to
compile them to one eco file.

There are also some tricky issues with having a single eco file at the
> moment, and ECLiPSe does not provide a way to do this currently.

Yup, I suppose I am having problems with those tricky issues. At first I
thought that the order in which the library files are included in this
single .eco file is the source of the problem, so I've tried to order the
files in the same way as when they are compiled but it did not solve the
problems. It is at least good to know that there is no official support for
what I am trying to.

I will try to work with the eclipse_rt package.

Joachim,
thanks for your suggestions, I'll drop the idea with the single .eco file.

Best regards
Luke