Another update to the archive.  Two changes, both for digc.

Easy one: a -install option has been added to digc that puts executables it creates in \dmd\bin, libraries in \dmd\lib, and DLLs in \windows\system32 or wherever the OS specifies.

Secondly: the stripped sources are now stuck on the end of created library files.  When it finds that dependent libraries have been loaded, it creates these files to act as an interface definition.  The upshot is that you don't need to install anything in \dmd\src, all the necessary information is in the library.  The library directory is automatically maintained, so a binary with just a .lib file would be enough in a distribution.  The downshot is that it slows down compilation, but not terribly so.

I had to depend on a couple more command.com commands, and I'm not sure these switches are available on all versions of Windows.  I'll get started on an OS module for doing these kinds of operations directly.

http://www.opend.org/dig/arc/dig-0.0.11.zip (Release)

Ilya Minkov wrote:
> Burton Radons wrote:
>  > I've updated the archive.  The main changes are in digc.  It behaves
>  >  closer to spec and adds a "-shared" option for when compiling
>  > libraries with "-lib=".  When that option is given, a DLL file is
>  > created as well as the import library for it.  The DLL exports all
>  > public symbols (generating a def and scanning the object files) and
>  > doesn't need a DllMain.
> 
> Thanks a lot!

Err, you're welcome, but I didn't make any changes for you.  In which thread did you recommend something along these lines?

>  > A utility called dstripcopy has been added as well, which removes
>  > comments and function bodies from D files and then copies it to the
>  > destination.  The cartoon example compiles 59% faster when using
>  > stripped dig headers.  This is actually the first stage of a
>  > two-stage plan - I plan to stick the stripped headers in lib files so
>  > that there's only one binary to install.
> 
> Great! But shouldn't the compiler care about saving this information in a suitable format together with additional information which has been figured out while compiling? Besides, tiny functions are better off not stripped since they could be inlined? This all is better off being saved in some parsed form, which a compiler could use almost directly.

An option to avoid stripping small final functions is in the future - it's really just an argument, comparison, and some context introspection away.  I think this should migrate into the compiler in the future, but it's good for the interface to be proven in tools first.  They're more flexible.

"Burton Radons" <loth@users.sourceforge.net> escribió en el mensaje
news:b57hdc$tfc$1@digitaldaemon.com...
| Another update to the archive.  Two changes, both for digc.
|
| Easy one: a -install option has been added to digc that puts executables
| it creates in \dmd\bin, libraries in \dmd\lib, and DLLs in
| \windows\system32 or wherever the OS specifies.
|
| Secondly: the stripped sources are now stuck on the end of created
| library files.  When it finds that dependent libraries have been loaded,
| it creates these files to act as an interface definition.  The upshot is
| that you don't need to install anything in \dmd\src, all the necessary
| information is in the library.  The library directory is automatically
| maintained, so a binary with just a .lib file would be enough in a
| distribution.  The downshot is that it slows down compilation, but not
| terribly so.
|
| I had to depend on a couple more command.com commands, and I'm not sure
| these switches are available on all versions of Windows.  I'll get
| started on an OS module for doing these kinds of operations directly.
|
| http://www.opend.org/dig/arc/dig-0.0.11.zip (Release)
|

In dedit, when I press a key, it exits with an Access Violation.

-------------------------
Carlos Santander
"Burton Radons" <loth@users.sourceforge.net> escribió en el mensaje
news:b57hdc$tfc$1@digitaldaemon.com...
| Another update to the archive.  Two changes, both for digc.
|
| Easy one: a -install option has been added to digc that puts executables
| it creates in \dmd\bin, libraries in \dmd\lib, and DLLs in
| \windows\system32 or wherever the OS specifies.
|
| Secondly: the stripped sources are now stuck on the end of created
| library files.  When it finds that dependent libraries have been loaded,
| it creates these files to act as an interface definition.  The upshot is
| that you don't need to install anything in \dmd\src, all the necessary
| information is in the library.  The library directory is automatically
| maintained, so a binary with just a .lib file would be enough in a
| distribution.  The downshot is that it slows down compilation, but not
| terribly so.
|
| I had to depend on a couple more command.com commands, and I'm not sure
| these switches are available on all versions of Windows.  I'll get
| started on an OS module for doing these kinds of operations directly.
|
| http://www.opend.org/dig/arc/dig-0.0.11.zip (Release)
|

In dedit, when I press a key, it exits with an Access Violation.

-------------------------
Carlos Santander

> | http://www.opend.org/dig/arc/dig-0.0.11.zip (Release)
> |
>
> In dedit, when I press a key, it exits with an Access Violation.

Me too. Found the fix since then?

Cheers,
Sab

> Secondly: the stripped sources are now stuck on the end of created library files.  When it finds that dependent libraries have been loaded, it creates these files to act as an interface definition.  The upshot is that you don't need to install anything in \dmd\src, all the necessary information is in the library.  The library directory is automatically maintained, so a binary with just a .lib file would be enough in a distribution.  The downshot is that it slows down compilation, but not terribly so.

Hehh, cool. I was thinking about the same idea lately,
but could not decide if I'd like it or not. The main
(another...) downside to me was the fact that I'd need
the interface code in a readable form _anyway_.

Sab

"Luna Kid" <lunakid@neuropolis.org> wrote in message news:b6psbq$4mt$1@digitaldaemon.com...
> > Secondly: the stripped sources are now stuck on the end of created library files.  When it finds that dependent libraries have been loaded, it creates these files to act as an interface definition.  The upshot is that you don't need to install anything in \dmd\src, all the necessary information is in the library.  The library directory is automatically maintained, so a binary with just a .lib file would be enough in a distribution.  The downshot is that it slows down compilation, but not terribly so.
>
> Hehh, cool. I was thinking about the same idea lately,
> but could not decide if I'd like it or not. The main
> (another...) downside to me was the fact that I'd need
> the interface code in a readable form _anyway_.

(I mean for development. For redistribution,
this embedding is the perfect solution.)

Sab

There's a bug in dig. If I create a frame only with a menu, the menu doesn't show up until I press Alt. However, if I put another control in the frame, the menu appears.

-------------------------
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.478 / Virus Database: 275 - Release Date: 2003-05-06

v0.0.12: Uh, see changelog.  No time with the ICFP.

http://www.opend.org/dig (Website)
http://www.opend.org/dig/arc/dig-0.0.12.zip (Release)
http://www.opend.org/dig/arc/dig_html-0.0.12.zip (Documentation pack)

error encountered during compilation/installation:

halhello

--- errorlevel 100

--- errorlevel 100

"Burton Radons" <loth@users.sourceforge.net> escribió en el mensaje
news:bdj3fl$2qg0$1@digitaldaemon.com...
| v0.0.12: Uh, see changelog.  No time with the ICFP.
|
| http://www.opend.org/dig (Website)
| http://www.opend.org/dig/arc/dig-0.0.12.zip (Release)
| http://www.opend.org/dig/arc/dig_html-0.0.12.zip (Documentation pack)
|

The only way I could install dig was under a completely new dmd installation. Obviously, when I tried to move it to where my real dmd is, it didn't work. I know this has happened since... mmm... a long time ago, but it's just a PITA, at least for me.

-------------------------
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 2003-06-25