Hi Matt,

All of Gambit's primitives for compilation, linking etc. already supports specification of output path, and Gambit itself is free of a packaging abstraction and leaves all of that for the user code (such as a specific user-implemented macro expander like one for syntax-case, even if bundled as an optional together with the Gambit distro) to implement atop Gambit's primitives.

Therefore there should be no need of changing Gambit's behavior with regard to what directories it outputs c/object/library/executable files into -

Perhaps this was what you meant already?


Metadata such as macros can be stored in one or more files specific your macro expander/module system, or if desired you can include such metadata as a predefined global or procedure call inside your output code and that way get it included in your output object files. For instance Black Hole does this.

For my reference, what's the visit/revisit about?

Best regards,
Mikael



2013/10/22 Matt Hastie <matthastie@gmail.com>

On Oct 22, 2013, at 8:43 AM, Marc Feeley <feeley@iro.umontreal.ca> wrote:

The main problem I see is one of *packaging*.

Yes, exactly. Compiled standards mode essentially forces a "cfront-style" repository of sources ... and this irreversibly alters Gambit in one way or another, so careful community planning and consultation is needed.

How to attach meta information (macros, etc) to a compiled file?  An interesting approach would be to put the result of compilation in a directory with subfiles with standardized names for the various parts.

I think this is an excellent idea, so long as GNU make et al can continue to get dependency analysis right. To effect this, it may be necessary to treat the directory creation as "atomic-as-possible" to prevent the creation of directory artifacts of various ages.

 For example, "gsc foo.scm" would create the directory foo.o1 containing the "normal" foo.o1 shared lib and foo.c (useful for Scheme level linking) and other files for the visit and revisit information.

Do you see this alteration as something for gambit mode too, or just standards mode? Even in gambit mode, it'd be nice to place the .c and _.c files in a .o<n> folder. Any migration of the .c and _.c will regress existing build art.

For standards mode, the win of compiled syntax may offset the loss of backwards compatibility with existing build systems - is this also true for gambit mode?

It is desirable to introduce a flag to denote 'new packaging' mode to minimize community disturbance?

For standards-mode, such a directory may contain as many as five files:

foo.scm -> foo.o1/{foo.o1,foo.c,foo_.c,foo.visit.scm,foo.revisit.scm}

Code changes shouldn't be too tough (that is, mechanical, not innovative), but the test matrix is the cross-product of:

{ Windows, UNIX } x { gambit-mode, standards-mode } x { exe, incremental link, flat link } x { visit/revisit test suite }

I should also check to see how the various other backends, javascript et al, work with this proposal.

In the meantime, I'll work towards a patch in conjunction with specification that comes from this thread.

Kind regards,
Matt.


_______________________________________________
Gambit-list mailing list
Gambit-list@iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list