iserv-bin configuration fails about hadrian

[bgamari]

The reason here appears to be that iserv has no Library component and ghc-cabal only produces inplace-pkg-config for packages with library components.

[bgamari]

I think all of this stems from the fact that Settings.isLibrary is fragile at best. @snowleopard, shouldn't the nature of a package be declared explicitly?

[snowleopard]

@bgamari Agreed. If you look into Package.hs, you'll see that I planned to add pkgType :: PackageType field to differentiate packages better. However it was not clear to me at that point which package types we want and whether types are mutually exclusive. Is this just data PackageType = Program | Library?

Any thoughts on this?

[bgamari]

@snowleopard strictly speaking it's a bit of a false-dichotomy. A Cabal package consists of one or more components. These may either be Library components (of which there is at most one) or (one or more) Executable components.

When we say a package is a library we mean that it has a LIbrary component. Perhaps we want this fact to be emitted in package-data.mk? This would eliminate the need to manually replicate this information in the build system, but would mean that querying whether or not a package is a library would involve a query to an oracle.

[snowleopard]

@bgamari I see. It looks though that in the GHC build system every package can be considered either a Library (in which case we generate a bunch of object/library files) or a Program (in which case we generate an executable or several executables in case of iserv). Is this correct? If yes, we can stick to the current design but, perhaps, make defaultProgramPath depend on Way in addition to Stage and Package.

We may want to be more ambitious and handle all possible cabal packages eventually, but this could be postponed.

By the way make didn't build iserv on my machine. Is it Linux specific?

[bgamari]

We may want to be more ambitious and handle all possible cabal packages eventually, but this could be postponed.

Yes, but I am wondering whether it might be worth doing it the right way from the start. Ultimately it doesn't seem that much harder and it seems ill-advised to have the build system's data model not match that of Cabal. Regardless, I've implemented the explicit approach in #8.

By the way make didn't build iserv on my machine. Is it Linux specific?

Hmm, at one point it was broken on Windows but Simon Marlow said he fixed it before merging it. Perhaps you need to pull or rerun boot?

[snowleopard]

Thanks for implementing PackageType etc! If you don't mind I'll rename setPkgType to setType for consistency with setPath.

Shall we consider this issue closed now? We'll come back to proper support of cabal packages at some point.

I'll try to get iserv working on my machine.

[bgamari]

I've opened #12 to track this potential refactoring. This can now be closed.