redundant methos

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

redundant methos

pdigonzelli
Hi all, I have some methods invoked by perform: .

When I am creating toGo .exe , these are deleted when i check "delete
redundant methods'.
I want to preserve this methods but I do not want to include real redundant
ones.
Exist a way to "mark" my methods as non redundant ones in order to preserve
them in the .exe creation process?

TIA
Pablo


Reply | Threaded
Open this post in threaded view
|

Re: redundant methos

Schwab,Wilhelm K
Pablo,

> Exist a way to "mark" my methods as non redundant ones in order to preserve
> them in the .exe creation process?

You can try the "must not strip" method category, but you also have to
beware of loose methods that get removed with a package that is
considered removable.  To prevent the latter kind of problem, you can
set a manual prerequesite in the properties of one of your packages.

There might also be another class of trouble: methods being removed with
a class that are to be unreferenced.  I run into related problems in an
app that has classes which would be named only in arriving data streams,
and created artificial references to keep them in the deployed
executables.  It finally turned out to be easier to disable class
stripping; the resulting exe size is <4MB as Lagoon correctly removes
many packages that are not needed.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: redundant methos

pdigonzelli
Thanks Bill. it works very well for me.

Pablo

"Bill Schwab" <[hidden email]> escribió en el mensaje
news:cqi3fa$68g$[hidden email]...
> Pablo,
>
> > Exist a way to "mark" my methods as non redundant ones in order to
preserve

> > them in the .exe creation process?
>
> You can try the "must not strip" method category, but you also have to
> beware of loose methods that get removed with a package that is
> considered removable.  To prevent the latter kind of problem, you can
> set a manual prerequesite in the properties of one of your packages.
>
> There might also be another class of trouble: methods being removed with
> a class that are to be unreferenced.  I run into related problems in an
> app that has classes which would be named only in arriving data streams,
> and created artificial references to keep them in the deployed
> executables.  It finally turned out to be easier to disable class
> stripping; the resulting exe size is <4MB as Lagoon correctly removes
> many packages that are not needed.
>
> Have a good one,
>
> Bill
>
> --
> Wilhelm K. Schwab, Ph.D.
> [hidden email]