Many way to build platform dependent items

27 views
Skip to first unread message

Vincent de RIBOU

unread,
Dec 16, 2016, 2:58:58 AM12/16/16
to libuv
Hi all,

I noticed that many ways are possible to build platform dependent items.
For example, native windows uses Python tool, when MinGW uses custom makefile and finaly autotools for posix platforms.

Since I am developping components on many platform types, I think it will be very interesting to have only one build system, whatever it could be.

What's your opinion?
Do you thnk it is possible?

How to validate all configs, complete LibUV solution or subcomponent  are included at the same time in all build systems?

Many thanks for your comments.

Saúl Ibarra Corretgé

unread,
Dec 16, 2016, 3:04:14 AM12/16/16
to li...@googlegroups.com
Hi!

On 12/16/2016 08:57 AM, Vincent de RIBOU wrote:
> Hi all,
>
> I noticed that many ways are possible to build platform dependent items.
> For example, native windows uses Python tool, when MinGW uses custom
> makefile and finaly autotools for posix platforms.
>
> Since I am developping components on many platform types, I think it
> will be very interesting to have only one build system, whatever it
> could be.
>

Why is that? You can just choose the right one for your usecase. Or
even others! There are some CMake files around maintained by third
parties, pick your poison :-)

> What's your opinion?
> Do you thnk it is possible?
>

Not really. On Windows and Unix one can use GYP, but not for MinGW. On
Unix one can use autotools, which is the most common approach. Last,
the MinGW makefile is gone from the master branch, since MinGW users can
use autoconf.

> How to validate all configs, complete LibUV solution or subcomponent
> are included at the same time in all build systems?
>

I don't understand what you ask here. Can you rephrase? If you worry
something won't work, we hace a pretty extensive CI which tests with
both build systems.


Cheers,

--
Saúl Ibarra Corretgé
bettercallsaghul.com


signature.asc

Vincent de RIBOU

unread,
Dec 16, 2016, 3:34:43 AM12/16/16
to libuv
Hi all,

my purpose is to share build systems with all possible platforms.
the current approcah needs to check for every changes that all build systems are compliant with those changes (new files, new platform dependent changes, ...).

Even if if i am not familiar with native windows programming (and tools to build with VSxxxx), I am not confident that using many build systems is the most flexible (or easiest way) for every one.
So if there will be a common build system for all platforms, it will be very helpful for anyone.

Can you tell me why MinGW is out of the main stream to build libUV?
Why it uses separate makefiles instead of autotools? (only history of libUV, specific consideration, something else).
Is it only many efforts to share/mutualise build systems?

Regards,

Saúl Ibarra Corretgé

unread,
Dec 16, 2016, 3:45:07 AM12/16/16
to li...@googlegroups.com
On 12/16/2016 09:34 AM, Vincent de RIBOU wrote:
> Hi all,
>
> my purpose is to share build systems with all possible platforms.
> the current approcah needs to check for every changes that all build
> systems are compliant with those changes (new files, new platform
> dependent changes, ...).
>

In an ideal world there would be one system to rule them all, but that's
not the case, so we use the most suitable ones, in our opinion, of
course. This has worked just fine for years. I still don't understand
what's your problem with libuv using multiple build systems, since you
don't have to maintain them. Pick one for your application, we make
sure it keeps working (except the MinGW makefile), this is not something
that gets changed on a whim.

> Even if if i am not familiar with native windows programming (and tools
> to build with VSxxxx), I am not confident that using many build systems
> is the most flexible (or easiest way) for every one.
> So if there will be a common build system for all platforms, it will be
> very helpful for anyone.
>

Can you given a specific example of a problem you are facing? I'd
rather discuss specifics than hypotheticals.

> Can you tell me why MinGW is out of the main stream to build libUV?

Because the MinGW ecosystem has matured enough (with MSYS2) so it's now
easy to use autotools instead, and we have one less makefile to maintain.

> Why it uses separate makefiles instead of autotools? (only history of
> libUV, specific consideration, something else).

autotools works for MinGW. GYP doesn't work very well IIRC so it's
discouraged on MinGW.

> Is it only many efforts to share/mutualise build systems?
>

I don't understand this.
signature.asc

Vincent de RIBOU

unread,
Dec 16, 2016, 3:56:07 AM12/16/16
to libuv
I have no technical issues.
I just have expected a world (not so utopic in my prospective) where the work is easier for all, especially for developpers of libUV.

If minGW is not synchronised with others plaforms build, it is a potential issue for me.
Sorry for the disturbance.

Le vendredi 16 décembre 2016 08:58:58 UTC+1, Vincent de RIBOU a écrit :

Saúl Ibarra Corretgé

unread,
Dec 16, 2016, 9:56:21 AM12/16/16
to li...@googlegroups.com
On 12/16/2016 09:56 AM, Vincent de RIBOU wrote:
> I have no technical issues.
> I just have expected a world (not so utopic in my prospective) where the
> work is easier for all, especially for developpers of libUV.
>

:-)

> If minGW is not synchronised with others plaforms build, it is a
> potential issue for me.
> Sorry for the disturbance.
>

No problem. If you want to make sure it works and continues to do so,
use autotools on MinGW.
signature.asc

Vincent de RIBOU

unread,
Dec 19, 2016, 4:08:01 AM12/19/16
to li...@googlegroups.com
success with autotools on mingw32.
sure mingw64 will work, :)

if I correctly understood, now MinGW specific makefile is not required since autotools woks.
right?


--
You received this message because you are subscribed to a topic in the Google Groups "libuv" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/libuv/p083CR-2Bmw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to libuv+un...@googlegroups.com.
To post to this group, send email to li...@googlegroups.com.
Visit this group at https://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.
--
Vincent de RIBOU
Maine et Loire - v.de...@gmail.com

Saúl Ibarra Corretgé

unread,
Dec 20, 2016, 6:12:12 PM12/20/16
to li...@googlegroups.com
On 19/12/16 10:07, Vincent de RIBOU wrote:
> success with autotools on mingw32.
> sure mingw64 will work, :)
>

\o/

> if I correctly understood, now MinGW specific makefile is not required
> since autotools woks.
> right?
>

Correct!

--
Saúl Ibarra Corretgé
http://bettercallsaghul.com

Vincent de RIBOU

unread,
Dec 21, 2016, 2:33:07 AM12/21/16
to li...@googlegroups.com
since not required, you should remove Makefile.mingw script.

--
You received this message because you are subscribed to a topic in the Google Groups "libuv" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/libuv/p083CR-2Bmw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to libuv+un...@googlegroups.com.
To post to this group, send email to li...@googlegroups.com.
Visit this group at https://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages