Re: Non-standard builds, autoconf and gcc

[Maxim Cournoyer]

Hello,

John Soo  writes:

> Hi Todor,
>
>
>> I am trying to define a package that builds a source which has
>> 
>> a non-standard build procedure. It's a mix of autotools packages and 
>> something else. My first attempt was to use the trivial builder...
>
> What is the something else? If it the shape of the build follows the
> gnu steps with some extra autotools, you may be able to use
> modify-phases. You would get the majority of the unpacking,
> replacement of relevant paths, and more. Then you could add some extra
> steps to work in the autotools specifics. My experience with the
> trivial builder is that it is best for union builds and copying some
> files but not much more.

+1

Good luck,

Maxim

Re: Non-standard builds, autoconf and gcc

[John Soo]

Hi Todor,


> I am trying to define a package that builds a source which has
> 
> a non-standard build procedure. It's a mix of autotools packages and 
> something else. My first attempt was to use the trivial builder...

What is the something else? If it the shape of the build follows the gnu steps 
with some extra autotools, you may be able to use modify-phases. You would get 
the majority of the unpacking, replacement of relevant paths, and more. Then 
you could add some extra steps to work in the autotools specifics. My 
experience with the trivial builder is that it is best for union builds and 
copying some files but not much more. 

Good luck,

John

Non-standard builds, autoconf and gcc

[Todor Kondić]

I am trying to define a package that builds a source which has

a non-standard build procedure. It's a mix of autotools packages and something 
else. My first attempt was to use the trivial builder, pull in the 
gcc-toolchain along with autotools and use

this mixture for the parts where they can be used. The usual auto(re)conf et 
cetera method.

This unfortunately is one huge mess: even when i patch the  resulting configure 
script not to use hardwired /bin/sh /lib/cpp and such, gcc checks always fail. 
The glibc, gcc-toolchain-X.Y.Z and gcc-X.Y.Z(-lib), as well as binutils, all 
have overlapping, but not entirely same libraries, includes and gcc programs.

My first question,  if I am unable to simply use the gnu build system, but need 
autotools functionality, which packages should I pull in as native inputs for a 
regular C program? Is it the gcc-toolchain, or the hidden package gcc? 
Additionally, should I pull in binutils and glibc? The second question is, how 
to set the build environment? I realised that just installing the gcc-related 
packages does not necessarily mean that gcc knows about where the heck its 
brains and guts are. How to set COMPILER_PATH, LIBRARY_PATH and any other 
relevant environment variables?

Finally, can I work around these problems by calling some of the functionality 
of gnu-build-system from the builder?
Something like,

; trivial system on top-level
.
.
.
#:builder (... do preparatory stuff ...
   (with-directory-excursion "subpackage"
(gnu-build-system-build-only ...)))
.
.
.

Cheers,

Todor