lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Using Git submodules for the dependencies


From: Greg Chicares
Subject: Re: [lmi] Using Git submodules for the dependencies
Date: Fri, 20 Sep 2019 15:08:08 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 2019-09-20 12:46, Vadim Zeitlin wrote:
> 
>  Another issue which arose again when thinking about the Linux build is
> that of getting the sources of various dependencies. We already have the
> existing install_xxx.{make,sh} scripts that do it, of course, and it
> probably shouldn't even take much, if anything, to make them work under
> Linux, but I can't help wondering why do we reimplement something that Git
> can perfectly well to do on its own.

That may be a good idea.

I'm not opposed to git submodules in principal. We've figure out
how to use them for wx. The current git implementation does work.

On the one hand, this might be helpful for a server that blocks
most of the free (software) world, even gnu.org .

On the other hand, I'm not sure the version of git that we're
working with supports submodules. I know for certain that it
doesn't support 'git clone jobs=', so it's at least more out of
date than debian old-stable.

But we might need to build a lot of tools from scratch if we
want this thing to work. We don't have 'make --output-sync',
which we can probably do without. We also don't have
'g++ -std=c++17', which is a hard requirement.

At this point, I'm struggling to get anything done on the
server. Each incremental step exposes more problems. For
example, installing EPEL didn't let me install MinGW-w64, but
I was able to do that with 'yum install --nogpgcheck'. I'd
like to post here a list of all the changes I'm making, but
first I need to figure out what changes are necessary. If (as
I think you said in a private message) you're able to install
the same version of RHEL we're using, then I should post what
I've done now, and then we could work on the remaining issues
together--two heads are better than one, especially when the
first one's mine and the second one, yours.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]