Makefile: use scons when compiling on a linux host #56

Merged
merged 4 commits into from Mar 19, 2015

Projects

None yet

2 participants

@leggewie
Contributor

A simple way to make the Makefile do the right thing on Linux as well. Similar thing could be done for OSX but I have no way to test.

@ereOn
Member
ereOn commented Mar 16, 2015

Awesome, thanks.

Have you checked this on Windows too ?

@ereOn ereOn added the enhancement label Mar 16, 2015
@ereOn ereOn added this to the 2.0 milestone Mar 16, 2015
@leggewie
Contributor

No, I have not touched a windows machine in years and I haven't owned one for more than ten years. It shouldn't change anything for windows, I believe. Would be good to have this tested on Win and MacOSX.

I don't understand why I am not receiving any notifaction mails from github. Strange...

@ereOn ereOn self-assigned this Mar 16, 2015
@ereOn
Member
ereOn commented Mar 16, 2015

I'm gonna test it this evening If I find the time.

@ereOn
Member
ereOn commented Mar 16, 2015

@leggewie I just tested and the proposed syntax does not work on Windows (with nmake).

That being said, I have no problem to merge this if:

  • You revert your changes to the Makefile and rename it Makefile.windows
  • You add a new Makefile for POSIX platforms only.

Would that be okay ?

@ereOn ereOn added the packaging label Mar 16, 2015
@leggewie
Contributor

Let's fix this properly is what I would suggest. When you say "does not work", what exactly fails and how?

I've always been surprised you are not using scons on windows. Isn't that supposed to work there as well?

@ereOn
Member
ereOn commented Mar 17, 2015

@leggewie nmake and make do not use the exact same format for Makefile, hence the suggestion to completely separate those two.

The Makefile for Windows is more a commodity than anything else : it's merely a reminder of the commands one has to type to compile from the terminal. Ideally this would be used by a Windows build machine, but I never could find time to setup one.

Regarding SCons on Windows... that was initially the case. I switched to Projects and Solutions because :

  • A lot of Windows folks were unfamiliar with SCons and would only understand Visual Studio : I perceived this as a limitation which would cause less people to contribute.
  • Maintaining both SCons for Windows and Visual Studio was too much trouble.
  • Visual Studio is a good debugging environment.

I know SCons can generate Visual Studio solutions, but the resulting solution/project files are weird : they are just a wrapper that calls SCons under the hood from within Visual Studio. I was never fully satisfied with the result.

All that being said, I suppose I could give SCons on Windows another go someday (I miss my perfect dependency tree and the compilation speed it brings). But I don't think it is wise to change that so close to the release.

Does that make sense ?

@leggewie
Contributor

Thank you for the explanation. I'm happy to consider the release requirements. Honestly, I don't really like the "separation in two files"-copout. That way, a simple "make" still won't do the right thing on either of the boxes.

You say that nmake and make do not use the same format. Do you know where and how they differ? I'm sure there is a way to write syntax to satisfy them both. I wrote the change such that things SHOULD have stayed the same UNLESS uname returned 'linux'. Obviously, it didn't quite work out that way but I still see that as the right approach. Leave things as they are, except if it is detected one way or the other that the build happens on a Linux machine.

@ereOn
Member
ereOn commented Mar 18, 2015

@leggewie I was more suggesting to have a Makefile for just *NIX systems in the end.

This way:

  • make would work on all *NIX systems (on which it is common).
  • nmake would have to be nmake -f Makefile.windows but that's ok, since I don't expect anybody to use it often, or, at all. (I don't).
  • If we ever switch back to SCons for Windows, the nmake specificity would disappear anyway.

I appreciate you willing to make this work on both systems, but I'm not sure it's worth the trouble. I would be happy to drop Windows support for Makefiles if it makes *NIX builds/packaging easier.

@leggewie
Contributor

well, maybe the best solution is then indeed to "git mv Makefile Makefile.nmake" or "git mv Makefile Makefile.windows". The Makefile was indeed creating a "problem" for the Debian build since that is what the debhelper command would pick up by default.

Alongside that renaming, I suggest to add a README.linux (and possibly README.osx) to indicate at the top-level what people need to do to build the package.

Sounds good?

@ereOn
Member
ereOn commented Mar 18, 2015

@leggewie Sounds perfect yes !

Thanks.

@leggewie
Contributor

Ready to merge, I think.

@ereOn ereOn merged commit 766f7dd into freelan-developers:master Mar 19, 2015
@ereOn ereOn referenced this pull request Mar 19, 2015
Closed

Clarify build instructions #32

@ereOn
Member
ereOn commented Mar 20, 2015

@leggewie For your information, I just reorganized the various README files (and moved the content of README.linux into the generic BUILD.md file). I believe things are a bit simpler that way for people to understand.

Let me know if you still think Linux instructions should be in their own files.

@leggewie leggewie deleted the unknown repository branch Mar 20, 2015
@leggewie
Contributor

That's fine. But I'm confused about the heading levels. You first talk about the third party directory then Debian, then building FreeLAN and then debugging. A restructuring is in order here, I believe.

What is a first, second and third-level heading in your format? I think it's =, - and ### respectively. Is it? That's kind of confusing. Maybe you can also do with just two levels?

@ereOn
Member
ereOn commented Mar 20, 2015

Indeed:

== is for top-level header, -- for second-level and the next levels are just ###, ####, and so on. That's standard Markdown.

I'm not sure to understand exactly what you find confusing though: the Debian section is a sub-section of the "Third-parties" one because there is a specific way of installing those third-parties on Debian.

The same goes for the Windows and Debugging sections which are sub-sections of the Building one because they give more specific details on the topic.

@leggewie
Contributor

I've never seen it before. I certainly do find it odd that the first two levels are below the header-text and third-level and below not only significantly switches the marker but also starts to put it in the front of the text. Is this really used anywhere else but github.com?

@leggewie
Contributor

Besides, underlining with = for first-level header and - for second-level and then switching to four # for the third-level does not seem to be Markdown. Markdown starts with a single hash and adds one for each level. That is easy to comprehend.

On that topic, I think I noticed your files usually have only one first-level header, don't they? You basically use that as some kind of executive summary of what to find in the file. Or am I mistaken?

@leggewie
Contributor

if you agree in principle I'd love to push another branch for your review eventually

@ereOn
Member
ereOn commented Mar 20, 2015

@leggewie : I always thought the ====thing was standard Markdown, my bad.

Sure, whatever changes/improvements you want to suggest, feel free to do so !

@leggewie
Contributor

Well,
= Header 1 =
== Header2 ==
etc. certainly is standard (mediawiki comes to mind), but mixing underlining and prepending with =, - and # was too much for my little brain to grok. ;-) I'll create a new branch.

@ereOn
Member
ereOn commented Mar 20, 2015

@leggewie Haha. I know the feeling : sometimes little things are really annoying. ;)

Thanks for your interest ! I really appreciate it.

I'm working hard on my side to finish all the tasks for the 2.0 release so that we can move forward the packaging phase soon !

@leggewie
Contributor

Well, you certainly don't want me to mess up with big changes right off the bat ;-)

@ereOn
Member
ereOn commented Mar 20, 2015

@leggewie I actually don't care much about who does what. As a long as a contribution is meaningful and can be of use to others, I will happilly consider it, no matter its size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment