finding the dependecies of cabal packages

[Isaac Jones]

Hi Brian.  Sorry if I was a little curt last time...

Brian Smith <brianlsmith at gmail.com> writes:

(snip)
>> So you are limiting what the packager can do to pre-determined build
>> infrastructures.  Cabal's interface is generic; anything could be in
>> that Setup file, including stuff that no one but the packager uses.
>
> "Packager" is the maintainer of a package for a given platform,
> seperate from the package author, right? 

I mean the author or whoever has created the cabal package, not the OS
package.  Sorry, I know it gets confusing (believe me ;)

(snip)
>> > If a package description had these entries:
>> >
>> >     Build-Infrastructure: Simple
>> >     Hooks: Setup (preBuild, postBuild, postClean)
>> >
>> > it has the three hooks mentioned, which are exported from the
>> > package's Setup module. Each hook is just a function with the same
>> > type it has from Distribution.Simple.UserHooks. Each implementations's
>> > setup tool would determine how to call these hooks.
>> 
>> But how do you call the user's hooks?  And what if they want to do
>> something that can't be done with hooks?
>
> Firstly, if "they" want to do something that can't be done by hooks,
> then it is likely that whatever they are doing isn't going to work in
> other Cabal-enabled tools like VHS.NET and other such tools

If those tools conform to the cabal interface, that is, the
command-line interface and the required fields of the .cabal file,
then the tool should work just fine.  All of the layered tools I know
of so far do not need to peer into the Setup file to determine which
build system they are using.

Maybe VS.NET assumes everyone is using the simple build
infrastructure?

> (one of which I am working on). 

Can you tell me more about the tool you're working on?

(snip)
> I guess the important point is that there should be a way from looking
> at the Cabal file to determine if a tool can be built using the
> equivalent of "defaultMain."

I think layered tools should avoid this wherever possible.  If layered
tools can't work by executing the setup script, you're going to lock
out the packages which roll their own build system.  Please try to
implement features which rely on the stated Cabal interface, or
propose extensions to the interface which won't block out users who
roll their own setup scripts.  I would much rather keep the
abstractions we've built and extend the interface rather than breaking
the abstraction altogether for people who roll their own setup
scripts.

> For example, an IDE might use the GHC API to implement an
> "incremental build" feature, which would rebuild projects upon
> detecting changes to the source files (like Eclipse
> does). Futhermore, it might want to provide context-sensitive
> features like autocomplete that Cabal doesn't provide, and that
> requires knowledge of all source code dependencies in the source
> code.

I don't understand what you mean; how does this involve the simple
build system if you're using the GHC API?

> Also, don't you think that GHCi should be able to read Cabal files so
> that you don't have to say "ghci -cpp -fglasgow-exts -package X
> -package Y -package Z MyModule" when all those options are already in
> the Cabal file?

That would definitely be cool.

>> > Now, if a package description had this entry:
>> >
>> >      Build-Infrastructure: Make
>> >
>> > Then, tools that don't have Make (e.g. VHS.NET) could gracefully say
>> > "Make is not a supported build infrastructure" or "Cannot build this
>> > package because make is not installed."
>> >
>> > Also, imagine being able to do this for a Cabal package that has:
>> >      Build-Depends: HUnit, HaXml
>> 
>> It seems to me that adding the single field that Duncan needs is a
>> better solution than completely changing the way cabal works, and
>> limiting the users in the process.
>
> I don't see how my suggestion is limiting users, 

It limits users by blocking out those who use their own build
infrastructure.

> or even completely changing the way Cabal works.

I thought you were suggesting that a stand-alone executable read and
interpret the .cabal file, then execute functions from only a
pre-determined set of build infrastructures.  Perhaps you're saying
that the stand-alone executable should run pre-determined build
infrastructures if it knows about them and otherwise the user has to
provide a Setup.lhs file which gets executed with the "system" call?

> I will say that the current system seems inconvenient. For example, I
> just made some changes to the Win32 library on my local machine. I
> wanted to build and install the new version of Win32 using Cabal. The
> .cabal file is there but there is no "Setup.hs." So, I either have to
> add a Setup.hs myself, or reuse an existing one that is somewhere
> else.

That library should have been distributed with the Setup.lhs file;
you're inconvenienced because they didn't follow the Cabal interface,
not because of the cabal interface.

> On one hand, it doesn't make sense to have dozens of identical
> "Setup.hs" files throughout fptools. On the other hand, every Cabal
> package is expected to have its own Setup.hs, AFAICT.

For now, it is the case that each cabal package must come w/ its own
Setup.lhs file.  I've been toying with the idea of including a
cabal-setup executable, which just calls defaultMain which can be used
if ppl do use the simple build infrastructure.  Right now the cabal
interface is conservative so we can get a better idea of how people
use it.  If 90% of people end up using the same Setup.lhs file, then
we'll probably stop requiring it and add a caveat that says "if
there's no Setup script, then use the 'standard' one."


peace,

  isaac