[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New build-system quest (premake4 t-engine)
From: |
Oleg Pykhalov |
Subject: |
Re: New build-system quest (premake4 t-engine) |
Date: |
Wed, 26 Jul 2017 09:25:11 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
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" …))
Thanks! Yes, it needs to be set as argument to “make”. This is exactly
what I did.
>> 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.
Yes, I think the same. There are also different versions of premake
which I believe works different. Might be tricky to do this.
>>> 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.
Good to know, thanks!
I'm a little bit confusing about kinda patching in “snippet” vs “phase”.
After I made both in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27691
I thought maybe I could move “snippet” to “phase”. What is the
difference?
Right now I think that “snippet” is for patching and “phase”
modification is for “make” modification. Could be both I guess, but
what about best practice?
(snippet
'(for-each (lambda (file)
(substitute* file
(("#elif defined(__FreeBSD__)" line)
(string-append
line " || defined(__GNUC__)"))))
'("src/music.h" "src/tSDL.h")))