Windows builds + makefiles (important for release)

[Bob Carpenter]

We can't really release until I finish the doc,
and I can't do that until I understand the builds.

I merrily went along documenting direct calls
to g++ from Unix in the first pass at the doc.

Now I have two problems:

1. Targets (and ?) differ on Windows. But I'm not sure
exactly how (Java beautifully encapsulated the distinctions
so I never had to worry about it).

I know there's a .exe involved somewhere and the paths
are different.

Do I also need to call make differently?

I'd like to indicate at least in a footnote
how Windows users might be able to use Stan!

Or should I just have a complete set of parallel
instructions? I suppose judging from Andrew's experience
on the install, I should be as explicit as possible in
every possible place someone might go off the rails
due to uncertainty.


2. We have introduced a pretty strong dependency
on make for building bin/stanc and bin/libstan.a.

So maybe I should give up all pretense of being able
to operate without make and just provide instructions
for building models based on make?

Daniel -- can you remind me what that looks like? I
couldn't quite understand the output of "make help":

- models/* : If a Stan model exists at src/models/*.stan, this target
will copy the Stan model to models/*.stan, then
build the
Stan model.
- * : If a Stan model exists at *.stan, this target will build
the Stan model as an executable.

Is there a way to build without copying the model and
all its data and then running from a different location?
Moving is OK for the tiny bugs models. But what does hte
second - * do?

- Bob

[Matt Hoffman]

One option on Windows is to provide precompiled binaries as part of
the distribution. (I guess we could do that for Intel Macs too.) That
would alleviate the need for make. But I'm not sure requiring gcc +
make is much more onerous than requiring just gcc. And I'd just as
soon not say we support Microsoft's Visual Studio compiler.

Matt

[Daniel Lee]

On Mon, Jul 23, 2012 at 6:01 PM, Bob Carpenter <ca...@alias-i.com> wrote:
> We can't really release until I finish the doc,
> and I can't do that until I understand the builds.
>
> I merrily went along documenting direct calls
> to g++ from Unix in the first pass at the doc.
>
> Now I have two problems:
>
> 1. Targets (and ?) differ on Windows. But I'm not sure
> exactly how (Java beautifully encapsulated the distinctions
> so I never had to worry about it).
>
> I know there's a .exe involved somewhere and the paths
> are different.
>
> Do I also need to call make differently?
>
> I'd like to indicate at least in a footnote
> how Windows users might be able to use Stan!
>
> Or should I just have a complete set of parallel
> instructions? I suppose judging from Andrew's experience
> on the install, I should be as explicit as possible in
> every possible place someone might go off the rails
> due to uncertainty.

The only difference between the two is that a ".exe" is required at
the end of the target for building executables. For make, the path
separators are the same.

I tried making the targets between windows and non-windows the same,
but couldn't figure out how to have make not build the target if the
executable (.exe file) exists on windows.

To run the executable, the path separator is "\". Windows will not
recognize "/" for the path to the executable from the command prompt.
From a cygwin window, "/" is fine.

> 2. We have introduced a pretty strong dependency
> on make for building bin/stanc and bin/libstan.a.
>
> So maybe I should give up all pretense of being able
> to operate without make and just provide instructions
> for building models based on make?
>
> Daniel -- can you remind me what that looks like? I
> couldn't quite understand the output of "make help":
>
> - models/* : If a Stan model exists at src/models/*.stan, this target
> will copy the Stan model to models/*.stan, then build
> the
> Stan model.
> - * : If a Stan model exists at *.stan, this target will build
> the Stan model as an executable.
>
> Is there a way to build without copying the model and
> all its data and then running from a different location?
> Moving is OK for the tiny bugs models. But what does hte
> second - * do?

Sorry about the confusing explanation. We can rewrite that. First off,
if there is a stan file at foo/bar.stan, you can build the model by
typing "make foo/bar" (for windows: "make foo/bar.exe"). That's what
the second target is supposed to do.

From a clean directory, this should build bin/stanc and bin/libstan.a,
so there isn't a need to explicitly build them.

For the first target, if the make target is
models/basic_distributions/normal, if there is a stan model at
models/basic_distributions/normal.stan, it will build that, if not, it
will copy the model and code from src/models/basic_distributions. The
only reason we have this target is to leave the src directory alone.
If we were to use the target src/models/basic_distributions/normal, we
would drop into the src/models/basic_distributions directory the cpp
file, normal.cpp, and the executable, normal. I figured it was easier
copying our models from src/models/ to models/ and building in that
directory rather than trying to set up git ignore rules for the cpp
files and the executables. (I think a .o file is also created in
directory)

If we want to get rid of that first target, we can.

[Ben Goodrich]

On Tuesday, July 24, 2012 10:30:13 AM UTC-4, Daniel Lee wrote:

For the first target, if the make target is
models/basic_distributions/normal, if there is a stan model at
models/basic_distributions/normal.stan, it will build that, if not, it
will copy the model and code from src/models/basic_distributions. The
only reason we have this target is to leave the src directory alone.
If we were to use the target src/models/basic_distributions/normal, we
would drop into the src/models/basic_distributions directory the cpp
file, normal.cpp, and the executable, normal. I figured it was easier
copying our models from src/models/ to models/ and building in that
directory rather than trying to set up git ignore rules for the cpp
files and the executables. (I think a .o file is also created in
directory)

If we want to get rid of that first target, we can.

You can put another .gitignore file in src/models/ to exclude whatever you want below it, which is probably everything except the .stan files and the .R files.

Ben
 

[Daniel Lee]

On Tue, Jul 24, 2012 at 11:32 AM, Ben Goodrich <goodri...@gmail.com> wrote:
> You can put another .gitignore file in src/models/ to exclude whatever you
> want below it, which is probably everything except the .stan files and the
> .R files.

Yes, I am aware of that. But I'm not sure if we'll want to have
hand-coded cpp models in the same location along side the .stan files.
It also makes it difficult to write a clean target if we do mix
hand-coded cpp models in the same directory.

Of course, we don't have hand-coded cpp models in the directories now,
so it's easy enough to blanket ignore cpp files and clean up cpp and
.o files, but it's not clear how to clean up the executables
systematically. Any ideas on how we could implement that?

[Ben Goodrich]

On Tuesday, July 24, 2012 11:43:46 AM UTC-4, Daniel Lee wrote:

You could do git rm -force src/models/ to get rid of any new files that got generated but are not tracked. I don't know of a good way to distinguish hand-coded .cpp files from .cpp files generated by stanc.

Ben
 

[Daniel Lee]

We aren't requiring a dependency on git for our builds, so that option is out.