I put on-line some code to demonstrate a simple way to do a project in ATS:
The Makefile I used is of a very simple style that can be easily adapted
for handling other projects:
The support in patsopt for computing file dependency (depgen) makes it very
convenient to generate
file dependency information that can used directly by ‘make’.
The support in patsopt for computing file dependency (depgen) makes it
very convenient to generate
file dependency information that can used directly by ‘make’.
Rather than have a set of idioms for writing makefiles for each project,
we could just say, we’re using gnu make, if you write some software in
ATS, include those makefiles from the $PATSHOME directory, and just
specify the information that’s unique about your project. Why have a
convention when you can just have a library?
I believe the gnu implemenetation of objective C provides something like
this, and Plan 9 From Bell Labs does something very similar throughout
it’s build system. The go programming language used this before they’d
written their own build tools.
Thoughts?
Quoting gmhwxi (2013-10-19 20:40:47)
FYI.
I put on-line some code to demonstrate a simple way to do a project
in
ATS:
VATS/DiningPhil/Makefile
The support in patsopt for computing file dependency (depgen) makes
it
very convenient to generate
file dependency information that can used directly by ‘make’.
–
You received this message because you are subscribed to the Google
Groups “ats-lang-users” group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to ats-lang...@googlegroups.com <javascript:>.
To post to this group, send email to ats-l...@googlegroups.com<javascript:>.
I can think of many ways of generating standalone C code from ATS source.
Probably the simplest way is to put all the ATS code of a project in one
single file.
Say you have foo1.dats and foo2.dats. Create a file of the name
standalone.dats
and put the following lines inside standalone:
local #include “./foo1.dats” in (nothing) end // using [local] to avoid
name collision
local #include “./foo2.dats” in (nothing) end // using [local] to avoid
name collision
Then do:
patscc -ccats standalone.dats
Then the generated standalone_dats.c is essentially what you want.
Do not replace staload/dynload in foo1.dats and foo2.dats with #include.
You still want to keep the structure of the project. Think of
standalone.dats
as a file solely for the purpose of packaging.
Of course, you still need various header files (that is, CATS-files in ATS)
in order
to compile standalone_dats.c?On Tuesday, December 24, 2013 11:25:20 PM UTC-5, Brandon Barker wrote:
At this point I am wondering if the ideal situation would be to have an
option to atscc to simply replace staload, dynload, etc. with #includes
when a “portable” argument is specified.
My code is pretty small, so I will probably just replace all
staload/dynloads with #includes for now (it is ATS1 anyway so I am not
requesting any new features for this purpose). I guess there is no reason
why this wouldn’t work with the garbage collector as well, right?
Merry Christmas
On Sunday, December 22, 2013 4:07:45 PM UTC-5, gmhwxi wrote:
Here is an example showing how to generate C code first from ATS source
and then compile
the generated C code all at once:
The support in patsopt for computing file dependency (depgen) makes it
very convenient to generate
file dependency information that can used directly by ‘make’.
Apologies if this has been covered previously, as I thought it had, but I
couldn’t find where.On Saturday, October 19, 2013 8:40:47 PM UTC-4, gmhwxi wrote:
FYI.
I put on-line some code to demonstrate a simple way to do a project in ATS:
The support in patsopt for computing file dependency (depgen) makes it
very convenient to generate
file dependency information that can used directly by ‘make’.
Rather than have a set of idioms for writing makefiles for each project,
we could just say, we’re using gnu make, if you write some software in
ATS, include those makefiles from the $PATSHOME directory, and just
specify the information that’s unique about your project. Why have a
convention when you can just have a library?
I believe the gnu implemenetation of objective C provides something like
this, and Plan 9 From Bell Labs does something very similar throughout
it’s build system. The go programming language used this before they’d
written their own build tools.
The support in patsopt for computing file dependency (depgen) makes it
very convenient to generate
file dependency information that can used directly by ‘make’.
At this point I am wondering if the ideal situation would be to have an
option to atscc to simply replace staload, dynload, etc. with #includes
when a “portable” argument is specified.
My code is pretty small, so I will probably just replace all
staload/dynloads with #includes for now (it is ATS1 anyway so I am not
requesting any new features for this purpose). I guess there is no reason
why this wouldn’t work with the garbage collector as well, right?
The support in patsopt for computing file dependency (depgen) makes it
very convenient to generate
file dependency information that can used directly by ‘make’.
Thanks for the hints - I was wondering if there was an automated way for
these dependencies (CATS, etc.) to be added in by atsopt, or a list of
files printed. At least for reading the help for atscc and atsopt (ATS1), I
didn’t see anything that stood out. gcc -MM seems to list a lot of stuff
that isn’t actually needed but is included by ATS just in case, so I guess
this is the best bet for the moment - I will give it a try.On Wednesday, December 25, 2013 4:13:09 PM UTC-5, gmhwxi wrote:
Merry Chrismas!
I can think of many ways of generating standalone C code from ATS source.
Probably the simplest way is to put all the ATS code of a project in one
single file.
Say you have foo1.dats and foo2.dats. Create a file of the name
standalone.dats
and put the following lines inside standalone:
local #include “./foo1.dats” in (nothing) end // using [local] to avoid
name collision
local #include “./foo2.dats” in (nothing) end // using [local] to avoid
name collision
Then do:
patscc -ccats standalone.dats
Then the generated standalone_dats.c is essentially what you want.
Do not replace staload/dynload in foo1.dats and foo2.dats with #include.
You still want to keep the structure of the project. Think of
standalone.dats
as a file solely for the purpose of packaging.
Of course, you still need various header files (that is, CATS-files in
ATS) in order
to compile standalone_dats.c?
On Tuesday, December 24, 2013 11:25:20 PM UTC-5, Brandon Barker wrote:
At this point I am wondering if the ideal situation would be to have an
option to atscc to simply replace staload, dynload, etc. with #includes
when a “portable” argument is specified.
My code is pretty small, so I will probably just replace all
staload/dynloads with #includes for now (it is ATS1 anyway so I am not
requesting any new features for this purpose). I guess there is no reason
why this wouldn’t work with the garbage collector as well, right?
Merry Christmas
On Sunday, December 22, 2013 4:07:45 PM UTC-5, gmhwxi wrote:
Here is an example showing how to generate C code first from ATS source
and then compile
the generated C code all at once:
The support in patsopt for computing file dependency (depgen) makes
it very convenient to generate
file dependency information that can used directly by ‘make’.