headers
Neil Mitchell | 2 Jul 2007 21:41
Picon
Gravatar

Location of generated files

Hi,

I'd like to change where Yhc puts generated files. I propose:

Every module gets assigned a "root" directory:
* foo/Main.hs has a root of "foo".
* foo/System/Cmd.hs, module System.Cmd, has a root of "foo".
* foo/System/Cmd.hs, module Cmd, has a root of "foo/System".

(Note that this is already done when searching for imports)

Every file with <ext> (where ext is one of hi, hbc,ycr,yca) will be created in:

* foo/Main.hs leads to foo/<dir-ext>/Main.<ext>
* foo/System/Cmd.hs, module System.Cmd, leads to foo/<dir-ext>/System.Cmd.<ext>

By default, <dir-ext> is "obj" for all extensions. The flag objdir
will allow the default <dir-ext> to be changed. The flag <ext>dir will
allow the location of <ext> files to be changed. For example
--hidir=hi would put all the hi files in foo/hi/Main.hi. --objdir=bar
will put all generated files in foo/bar/*.*.

There is exactly one exception to this rule:

foo/Foo.hs, module Main, creates foo/Foo.hbc, in all circumstances.

Comments? If the argument you use relies on some other compiler
(GCC/GHC) doing something different, please say _why_ that compilers
behaviour is preferable.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stefan O'Rear | 2 Jul 2007 22:19
Picon

Re: Location of generated files

On Mon, Jul 02, 2007 at 08:41:31PM +0100, Neil Mitchell wrote:
> Hi,
> 
> I'd like to change where Yhc puts generated files. I propose:
> 
> Every module gets assigned a "root" directory:
> * foo/Main.hs has a root of "foo".
> * foo/System/Cmd.hs, module System.Cmd, has a root of "foo".
> * foo/System/Cmd.hs, module Cmd, has a root of "foo/System".
> 
> (Note that this is already done when searching for imports)
> 
> Every file with <ext> (where ext is one of hi, hbc,ycr,yca) will be created 
> in:
> 
> * foo/Main.hs leads to foo/<dir-ext>/Main.<ext>
> * foo/System/Cmd.hs, module System.Cmd, leads to 
> foo/<dir-ext>/System.Cmd.<ext>
> 
> By default, <dir-ext> is "obj" for all extensions. The flag objdir
> will allow the default <dir-ext> to be changed. The flag <ext>dir will
> allow the location of <ext> files to be changed. For example
> --hidir=hi would put all the hi files in foo/hi/Main.hi. --objdir=bar
> will put all generated files in foo/bar/*.*.
> 
> There is exactly one exception to this rule:
> 
> foo/Foo.hs, module Main, creates foo/Foo.hbc, in all circumstances.
> 
> Comments? If the argument you use relies on some other compiler
(Continue reading)

Permalink | Reply | 1 comment |
headers
Neil Mitchell | 2 Jul 2007 22:53
Picon
Gravatar

Re: Location of generated files

Hi

> This sounds like a very reasonable proposal, and I will take it for my
> project as well.

Good :) You are welcome to use the Make library as well - I
deliberately wrote it to target all compilers and Cabal.

> My only concern is that some projects have obj/ dirs containing very
> important sources (3D object models, etc) so we will need to be a bit
> careful in the implementation of clean.

True. I would have thought that few of these projects put Haskell
sources at the root level, then their important objects underneath.
However, if we restrict to cleaning .hi, .hbc etc we should be ok. At
the moment there is no yhc clean command, so it can be done later.

> Also, when you say 3kb yhc-specific - how much of that relates to
> invoking yhc, and how much is for building yhc?

That all relates to invoking Yhc on Haskell files. This mainly
involves building a list of dependent modules, then extracting rules
from this dependency information. The make library is already in the
tree (src/libraries/make), and I'll hopefully have committed the
Make2.hs tonight.

Thanks

Neil
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Mitchell | 2 Jul 2007 23:21
Picon
Gravatar

Re: Location of generated files

Hi

> What about
>  * foo/System/Cmd.hs, module Data.Whatever
> or other ridiculous arrangements, where the actual module name contains
> some number of dots greater than zero but doesn't match the directory
> structure.

Similar to putting module Foo in Bar.hs. There is no chance this will
ever be found by the compiler, so we emit an error. The one exception
is module Main, which can have any file name.

> You may want to allow filenames that replace some slashes with dots, such as
>  * foo/System.Cmd.hs, module System.Cmd
>  * foo/System/FilePath.Posix.hs, module System.FilePath.Posix
> both of which should have root "foo", I think.

Yes, I did intend to allow this. This is only an issue for finding the
root, everything else works out as before.

> Anyway, please don't look in the source directory for .hi files
> (assuming one didn't explicitly tell it to), it confuses yhc when
> looking at something ghc's been compiling.

Ah, good point! I've been bitten by this before, in the other
direction, with GHC reading Yhc's .hi files. I guess this is another
reason why this proposal is better than the current situation.

How about we default to being "yhc_obj" instead of "obj" - that way we
get a clear Yhc specific location, we won't clash with qhc, and we
(Continue reading)

Permalink | Reply | 1 comment |
headers
Isaac Dupree | 3 Jul 2007 01:04
Favicon

Re: Location of generated files


Neil Mitchell wrote:
> Hi
> 
>> What about
>>  * foo/System/Cmd.hs, module Data.Whatever
>> or other ridiculous arrangements, where the actual module name contains
>> some number of dots greater than zero but doesn't match the directory
>> structure.
> 
> Similar to putting module Foo in Bar.hs. There is no chance this will
> ever be found by the compiler, so we emit an error. The one exception
> is module Main, which can have any file name.

good. What if Yhc is explicitly invoked on a module other than Main -
then Yhc will "find" that file, right? (assuming yhc supports partial
compilation). In that case I would be happy with giving an error, or
putting the obj-dir in the same place as the file (what if it is used
like main, via some sort of -main-is - and there is always
hugs/ghci-like usage)

> How about we default to being "yhc_obj" instead of "obj" - that way we
> get a clear Yhc specific location, we won't clash with qhc, and we
> don't run the risk of trampling anyone's image data etc.

seems good.

Cabal can set that directory's position/name to be wherever it wants
inside its own build directory, okay.
(Continue reading)

Permalink | Reply | 0 comments |
headers
andrewjwilkinsonw | 3 Jul 2007 03:02
Picon

buildbot failure in gentoo_x86

The Buildbot has detected a new failure of gentoo_x86.
Full details are available at:
 http://www.indiegigs.co.uk:8010/gentoo_x86/builds/216

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: markus1

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Neil Mitchell

BUILD FAILED: failed yhc

sincerely,
 -The Buildbot
Permalink | Reply | 0 comments |
headers
andrewjwilkinsonw | 3 Jul 2007 03:02
Picon

buildbot failure in debian_amd64

The Buildbot has detected a new failure of debian_amd64.
Full details are available at:
 http://www.indiegigs.co.uk:8010/debian_amd64/builds/248

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: debianamd64

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Neil Mitchell

BUILD FAILED: failed yhc

sincerely,
 -The Buildbot
Permalink | Reply | 0 comments |
headers
andrewjwilkinsonw | 3 Jul 2007 03:02
Picon

buildbot failure in linux_ppc

The Buildbot has detected a new failure of linux_ppc.
Full details are available at:
 http://www.indiegigs.co.uk:8010/linux_ppc/builds/163

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: linuxppc

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Neil Mitchell

BUILD FAILED: failed yhc

sincerely,
 -The Buildbot
Permalink | Reply | 0 comments |
headers
andrewjwilkinsonw | 3 Jul 2007 03:03
Picon

buildbot failure in slack_x86

The Buildbot has detected a new failure of slack_x86.
Full details are available at:
 http://www.indiegigs.co.uk:8010/slack_x86/builds/251

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: slackx86

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Neil Mitchell

BUILD FAILED: failed yhc

sincerely,
 -The Buildbot
Permalink | Reply | 0 comments |
headers
andrewjwilkinsonw | 3 Jul 2007 11:32
Picon

buildbot failure in macosx_x86

The Buildbot has detected a new failure of macosx_x86.
Full details are available at:
 http://www.indiegigs.co.uk:8010/macosx_x86/builds/195

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: macosxx86

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Neil Mitchell

BUILD FAILED: failed yhc

sincerely,
 -The Buildbot
Permalink | Reply | 0 comments |

Gmane