Change makefile

[Tieqiong]

fix #18

[sbillinge]

@Tieqiong I should be able to merge this if you can show the diff

[Tieqiong]

@sbillinge

[sbillinge]

This looks good. Is there a reason you are building the BASENAME dynaically and not statically? In general we like to keep things simple for easier and clearer maintenance, but if there is a good reason for doing it this way we can talk about it.

[Tieqiong]

@sbillinge I think this is helping messages

This looks good. Is there a reason you are building the BASENAME dynaically and not statically? In general we like to keep things simple for easier and clearer maintenance, but if there is a good reason for doing it this way we can talk about it.

I made this to replicate diffpy.utils file, which instead of $(BASENAME).* it has diffpyutils.*. This is defining a help message so I assume this is default for sphinx?

[sbillinge]

@sbillinge I think this is helping messages

This looks good. Is there a reason you are building the BASENAME dynaically and not statically? In general we like to keep things simple for easier and clearer maintenance, but if there is a good reason for doing it this way we can talk about it.

I made this to replicate diffpy.utils file, which instead of $(BASENAME).* it has diffpyutils.*. This is defining a help message so I assume this is default for sphinx?

I guess my question was why you didn't just have it do diffpypackagename.* if the package is called diffpy.packagename. What is the added benefit of defining $(BASENAME) which then resolves to diffpypackagename.

[Tieqiong]

oh I thought all the cookiecutter attribute have the dot inside, that's why I need to define BASENAME to remove the dot

[sbillinge]

I thin

oh I thought all the cookiecutter attribute have the dot inside, that's why I need to define BASENAME to remove the dot

I think your way would work, but a huge effort went into making the release scripts work, and things that should have worked didn't etc.., so we are nervous about changing anything.....

[Tieqiong]

Or maybe I can make it static, just to change it to something like "projectname.*" instead of the actual project name

[sbillinge]

Or maybe I can make it static, just to change it to something like "projectname.*" instead of the actual project name

static means here that it has the actual project name after the cookie cutter runs.

[Tieqiong]

We have to remove the dot in some way, either inside this file (which we want to avoid?) or in the json (which is also a bad idea)...

[sbillinge]

Some parsing of this is being done by @Sparks29032 already if we can make use of that, though I think it happens in the post-process.

Your approach might work, but its hard to test it until we make a release with this new structure. If there is a way to not do it that s not too clunky that would be better.

[Sparks29032]

@sbillinge Two options:

1. We go with @Tieqiong's edits, which seem fine. Below is a comparison of devhelp and qthelp made by the original and new makefiles.

   Though the .gz files differ, after unzipping, the result is the same.

   Similarly, the html shows no discrepancy (as long as python -m build is as the searchindex.js will change if the metadata of one is not up to date), the resulting diff is very ugly.

2. We create a new variable in the cookiecutter.json file that removes the . as default value.

[sbillinge]

awesome guys, great work! Getting there.