Re: New build-system quest (premake4 t-engine)

[Ricardo Wurmus]

Hi Oleg,

> Ricardo Wurmus <address@hidden> writes:
>
>> Have you tried using the “gnu-build-system” and replacing the configure
>> phase with your invocation of premake4?
>
> I did it like you wrote.
>
> But the problem was tome4 (t-engine) wants config=release.

I’m not sure what this means, but if this is an argument to “make” you
can pass it to the build phase with the #:make-flags field of the
build system arguments.

If it’s about the invocation of premake you would just do that in your
replaced configure phase:

    (zero? (system* "premake4" "config=release" …))

> Firstly I thought that it will be good to have a different build system
> for premake in future, so we don't need always to overwrite configure
> phase.
>
> May be I'm wrong and it's OK to do all the time, I'm not sure.

It might be useful, but I don’t know how often that would be needed.
Our build systems so far each cover a very large number of packages.  If
it turns out that many more packages would need to do the same steps I
think it would be fine to add a new build system.

>> One difference between “guix build” and “guix environment” is that the
>> latter builds a profile first, so environment variables for libraries or
>> headers really only have to be set to a single directory
>> (e.g. $GUIX_ENVIRONMENT/lib or $GUIX_ENVIRONMENT/include).
>>
>> “guix build”, on the other hand, builds up long chains of directories as
>> the values for these environment variables.
>
> Hm, do they both produce kinda the same environment in native?

It’s similar, but not the same.  Some applications cannot really deal
with a search path that involves multiple directories.  PyQt, for
example, only looks in a single hard-coded directory for extensions, so
it would find them inside of “guix environment” but not in a build
environment.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net